Discussion :

[dev01]

Salut.

Je suis entrain en travailler sur EntityFramework et je me heurte à un problème que je n'arrive pas à résoudre.

Je souhaite acceder à mes collections d'objets EntityFramework à partir de plusieurs thread et toujours à partir de l'ObjectContext. Hors cet bippppp d'entityFramework referme la connexion à la base de données après chaque requete et cela provoque des erreurs lors de la vérification de l'état de la connexion pour l'exécution de requetes supplémentaires.


Ma question du jour : Avez vous travaillez avec EF et les thread ? Avez réussi à contourner cette grosse limitation ?

[anthyme]

l'object context n'est pas fait pour etre utiliser par plusieurs thread tu doit en instancier un minimum par thread

[dev01]

l'object context n'est pas fait pour etre utiliser par plusieurs thread tu doit en instancier un minimum par thread

Ouais ça j'avais remarqué, la question c'est : est ce que l'on peux passer outre cette énorme limitation ? Le problème rencontré pour l'instant dans l'accès multi thread c'est cette connexion fermé. En comme la classe EntityConnection est marqué sealed donc impossible d'en hérité pour inserer le comportement voulu.

D'ailleurs pourquoi ne pas avoir fait directement quelque chose de thread-safe ?

[anthyme]

la volonté de microsoft n'est pas d'avoir un objet usine a gaz qui contient tout une copie de la base dedant ... l'objectcontext est et doit être un objet a courte durée de vie.

je ne sais pas comment est ton architecture.

par exemple en Web asp.net je créer un objectcontext au début d une request que je stoc dans l'httpcontext courant puis je le detruit à la fin.

Dans une appli SOA tu pourrais instancier ton object context au sein de tes manager avec du code du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
using(var ctx = new MyObjectContext())
{
//Utilisation du context
}

[B.AF]

Ce n'est pas propre à EF mais à la plupart des ORM.

Et heureusement.

Ta solution réside dans :
La solution d'anthyme qui reste pour moi la plus fiable
Développer un service avec des slots qui te permette de te retourner systèmatiquement un contexte "propre".

Tu as davantage besoin d'une factory que de repenser le modèle de contexte de EF qui en plus est très sensible (du fait d'une très grande abstraction)/

[dev01]

J'utilise simplement différents thread pour inserer des données dans la base. La durée de vie de l'objet n'est que de quelque minute. Le problème n'est pas de trimbaler un objectContext à travers toute l'application, on est bien d'accord que ce n'est pas fait pour ça (quoique la notion de cache pourrait induire que si ... ) mais de faire de l'accès multi thread.

[B.AF]

Donc tu as davantage besoin d'un service singleton avec une synchronisation.

Le problème n'est pas dans EF (Pour moi)

[dev01]

Donc tu as davantage besoin d'un service singleton avec une synchronisation.

?? ? je vois pas l'interet de s'embeter à multi threader une app si c'est pour avoir un goulet d'étranglement qui encapsule le Insert ... Dans ce cas je programme tout en linéaire ça va plus vite (dans tout les sens du terme )

[B.AF]

tu n'es pas non plus obligé de passer par static et le synlock.

[anthyme]

je ne comprend pas bien ... si tu utilisent bien des isntance différente de ton objectcontext dans tes différents thread il n y a pas de raisons pour que l'un ferme la connexion de l'autre ...

[dev01]

tu n'es pas non plus obligé de passer par static et le synlock.

Peux tu détailler stp ? je comprend pas le concept d'un service singleton (ça okay) avec synchro (toujours okay) mais sans static (à la limite) et surtout sans outil de synchro ..

[B.AF]

public sealed class Singleton
{
static readonly Singleton instance=new Singleton();
static Singleton()
{
}

Singleton()
{
}

public static Singleton Instance
{
get
{
return instance;
}
}
}

Ca devrait suffire.
Chaque thread pourra accéder à un context propre.

[dev01]

Je vais être enquiquinant mais c'est pas grave, j'aime ça :
On est bien d'accord qu'il y a du static dans ton code ?

Ca devrait suffire.
Chaque thread pourra accéder à un context propre.

En je vois pas en quoi le fait d'avoir un singleton permet d'éviter les concourents.

Je ne cherche pas à avoir un ObjectContext par thread, mais bien un ObjectContext pour tout les thread

D'ailleur EntityFramework a t-il les même limitations que Linq To Sql concernant la liaison d'entité provenant de deux ObjectContext différent ? Je m'explique :
J'ai un OC A qui récupere un objet toto de la base. J'ai un OC B qui récupere un objet tata de la base. L'objet toto possède une propriété Tata de type tata? je veux lier tata à toto par cette propriété. Est-ce possible ?

[dev01]

je ne comprend pas bien ... si tu utilisent bien des isntance différente de ton objectcontext dans tes différents thread il n y a pas de raisons pour que l'un ferme la connexion de l'autre ...

On est bien d'accord mais ce n'est pas le but

[B.AF]

Ben si.

Si tu pars du principes que tu n'as qu'un ObjectContext pour un nombre inconnu de threads, comment veux-tu justement garantir qu'il ne puisse pas y avoir de goulet d'étranglement ?

quand je te parle d'utiliser un singleton, c'est simplement pour encpasuler la gestion de l'entityconnection de ton context, pas plus.

Si ton problème est typiquement de pouvoir contrôler l'état de ta connection, tu peux donc encapsuler cela en :
Créant une entityconnection
En vérifiant l'état de la connection ou en t'abonnement à l'événement StateChange.
Qui te permettraient éventuellement de manipuler la connection de l'objectcontext de façon transparente.

Non?

[dev01]

Ben si.

Si tu pars du principes que tu n'as qu'un ObjectContext pour un nombre inconnu de threads, comment veux-tu justement garantir qu'il ne puisse pas y avoir de goulet d'étranglement ?

quand je te parle d'utiliser un singleton, c'est simplement pour encpasuler la gestion de l'entityconnection de ton context, pas plus.

Si ton problème est typiquement de pouvoir contrôler l'état de ta connection, tu peux donc encapsuler cela en :
Créant une entityconnection
En vérifiant l'état de la connection ou en t'abonnement à l'événement StateChange.
Qui te permettraient éventuellement de manipuler la connection de l'objectcontext de façon transparente.

Non?

Sauf erreur de ma part l'EntityConnection est géré directement par l'ObjectContext (c'est lui qui ouvre et ferme la connexion). De plus cette classe est marqué sealed, impossible de surcharger la méthode Close pour l'inhiber. Enfin s'abonner à l'évènement StateChange ne résout pas le problème, en environnement multi thread il se peut que tu ai l'évènement après qu'un autre thread ai essayé de se connecter.

Enfin bref c'est pas possible et c'est la galère.

[B.AF]

Si tu veux je peux demander à un de mes "gars" de regarder, il avait scoré EF à l'époque et justement, le MT en faisait parti.

Si cela peut t'être utile.

[anthyme]

Faut pas chercher midi a 14h ...

Pour le multi threading soit tu a un objetcontext par thread soit tu as un seul object context mais tu dois le locker a chaque accès ... c'est la même façon de faire que le datacontext de linq to sql

pourquoi tu veux à tout pris un seul object context ?

[B.AF]

Ca va poser des problèmes de change Tracking.

EF track au niveau context, pas au niveau objet.

Le pattern DAO que tu décris 1 contexte pour un service est valable uniquement pour certains outils qui disposent d'une factory ou d'un repository de session. Donc il disposent d'un niveau supérieur permettant de connaitres les entités exploitées par chaque factory.

Potentiellement, il peut recontrer des dysfonctionnements bien plus gênants que le problème de connexion.

Sur tous les ORM, le stale object state est une "pain in the ass"

[stephane.julien]

Salut,

Je relis ce POST et j'ai du mal à comprendre ceci :

Je ne cherche pas à avoir un ObjectContext par thread, mais bien un ObjectContext pour tout les thread

Je ne comprends pas bien le sens, du fait qu'EDM ne gère pas (encore) de caching dans sa version de base..