http://www.dotnetguru2.org/sami/index.php?disp=comments fr-FR http://backend.userland.com/rss 60 Wed, 25 Aug 2004 07:38:02 +0000 Olivier Abrivard [Visiteur] c76@http://www.dotnetguru2.org/ Merci pour la r&#233;ponse.<br /> Je suis tout &#224; fait d'accord sur le fait d'&#233;viter les transactions longues. HttpContext.Current.Items ne peut pas permettre le "stockage temporaire" d'une transaction dont la dur&#233;e de vie est sup&#233;rieure &#224; la WebRequest car sa dur&#233;e de vie est justement la m&#234;me qu'une WebRequest.<br /> Ma remarque sur [ThreadLocal] portait sur la notion de r&#233;utilisation d'un Thread existant par IIS : je craignais de voir un Thread interrompu par IIS (une sorte de multi-activit&#233;s au sein du thread comme on a du multi-thread au sein d'un processus) et donc de voir le pattern "Thread Local Storage" remis en cause dans le cas d'une utilisation via ASP.Net. Apparemment ce n'est pas le cas puisque tu indiques que le ThreadID de la WebRequest ne bouge pas au cours de son ex&#233;cution.<br /> Merci encore pour ces &#233;claircissements. Je suis tout à fait d'accord sur le fait d'éviter les transactions longues. HttpContext.Current.Items ne peut pas permettre le "stockage temporaire" d'une transaction dont la durée de vie est supérieure à la WebRequest car sa durée de vie est justement la même qu'une WebRequest.
Ma remarque sur [ThreadLocal] portait sur la notion de réutilisation d'un Thread existant par IIS : je craignais de voir un Thread interrompu par IIS (une sorte de multi-activités au sein du thread comme on a du multi-thread au sein d'un processus) et donc de voir le pattern "Thread Local Storage" remis en cause dans le cas d'une utilisation via ASP.Net. Apparemment ce n'est pas le cas puisque tu indiques que le ThreadID de la WebRequest ne bouge pas au cours de son exécution.
Merci encore pour ces éclaircissements.]]> http://www.dotnetguru2.org/sami/index.php/2004/07/26/l_api_system_transactions#c76 Thu, 19 Aug 2004 13:37:25 +0000 admin [Membre] c72@http://www.dotnetguru2.org/ Bonjour Olivier,<br /> Tr&#232;s bonne question. Si une transaction doit avoir une dur&#233;e de vie sup&#233;rieure &#224; celle d'une WebRequest, alors effectivement il vaut mieux utiliser HttpContext.Current.Items. Ceci dit, il faut garder &#224; l'esprit que la transaction est initi&#233;e dans la couche de service (BLL) et sa dur&#233;e de vie est souvent &#233;gale &#224; celle du service (le ThreadID de la WebRequest ne bouge pas entre deux appels de m&#233;thode BLL).<br /> Ce cas de figure peut se produire lorsqu'on utilise des Transaction "longues", d&#233;conseill&#233;e dans la mesure du possible.<br /> <br /> Sami Très bonne question. Si une transaction doit avoir une durée de vie supérieure à celle d'une WebRequest, alors effectivement il vaut mieux utiliser HttpContext.Current.Items. Ceci dit, il faut garder à l'esprit que la transaction est initiée dans la couche de service (BLL) et sa durée de vie est souvent égale à celle du service (le ThreadID de la WebRequest ne bouge pas entre deux appels de méthode BLL).
Ce cas de figure peut se produire lorsqu'on utilise des Transaction "longues", déconseillée dans la mesure du possible.

Sami]]> http://www.dotnetguru2.org/sami/index.php/2004/07/26/l_api_system_transactions#c72 Thu, 19 Aug 2004 12:50:37 +0000 Olivier Abrivard [Visiteur] c71@http://www.dotnetguru2.org/ Bonjour,<br /> <br /> Je viens juste de parcourir l'article et je me pose une question sur l'acc&#232;s &#224; "Transaction.Current" et sur le pattern "Thread Local Storage". Si j'ai bien compris, tu dis que ce pattern est mis en oeuvre gr&#226;ce &#224; un champ statique "unique par thread" (attribut [ThreadStatic]). Or ce type de champs pose probl&#232;me lors d'une utilisation via ASP.NET 1.0 et IIS (r&#233;utilisation des threads par IIS) : le champ est bien unique par thread mais pas unique par requ&#234;te (je ne suis pas s&#251;r de ce que j'avance car c'est li&#233; &#224; une simple exp&#233;rimentation perso => je n'ai pas trouv&#233; de doc &#224; ce sujet). <br /> Un m&#234;me champ peut donc se retrouver partag&#233; par plusieurs utilisateurs, ce qui pose probl&#232;me pour la transaction courante.<br /> Pour contourner ce probl&#232;me on peut utiliser une zone de stockage unique par requ&#234;te et non unique par thread (System.Web.HttpContext.Current.Items) en ASP.NET 1.0.<br /> Ma question est "Dans .Net 2.0, Microsoft a-t-il modifi&#233; le comportement de l'attribut [ThreadLocal] de fa&#231;on a ce que l'interaction avec IIS soit plus fiable ?"<br />
Je viens juste de parcourir l'article et je me pose une question sur l'accès à "Transaction.Current" et sur le pattern "Thread Local Storage". Si j'ai bien compris, tu dis que ce pattern est mis en oeuvre grâce à un champ statique "unique par thread" (attribut [ThreadStatic]). Or ce type de champs pose problème lors d'une utilisation via ASP.NET 1.0 et IIS (réutilisation des threads par IIS) : le champ est bien unique par thread mais pas unique par requête (je ne suis pas sûr de ce que j'avance car c'est lié à une simple expérimentation perso => je n'ai pas trouvé de doc à ce sujet).
Un même champ peut donc se retrouver partagé par plusieurs utilisateurs, ce qui pose problème pour la transaction courante.
Pour contourner ce problème on peut utiliser une zone de stockage unique par requête et non unique par thread (System.Web.HttpContext.Current.Items) en ASP.NET 1.0.
Ma question est "Dans .Net 2.0, Microsoft a-t-il modifié le comportement de l'attribut [ThreadLocal] de façon a ce que l'interaction avec IIS soit plus fiable ?"
]]> http://www.dotnetguru2.org/sami/index.php/2004/07/26/l_api_system_transactions#c71 Mon, 26 Jul 2004 17:25:12 +0000 Léon Andrianarivony [Visiteur] c34@http://www.dotnetguru2.org/ Je suis curieux de savoir le choix de changer la valeur par d&#233;faut du IsolationLevel &#224; Serializable par rapport &#224; celui Read Commmitted qui est par d&#233;faut actuellement ? http://www.dotnetguru2.org/sami/index.php/2004/07/26/l_api_system_transactions#c34