Comments on: Abstracting Request State http://davybrion.com/blog/2009/01/abstracting-request-state/ Trying to walk that thin line between intelligence and ignorance Tue, 16 Mar 2010 21:33:15 +0100 http://wordpress.org/?v=2.9.2 hourly 1 By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-32029 Davy Brion Mon, 15 Mar 2010 08:03:58 +0000 http://davybrion.com/blog/?p=857#comment-32029 @Kurt the ActiveSessionManager class (found here: http://davybrion.com/blog/2009/12/using-nhibernate-in-your-service-layer/) uses the RequestState to store and retrieve the NHibernate ISession instance for the current request. You create the ISession instance at the beginning of the request (in my case, through the construction of my UnitOfWork), and you get rid of it at the end of the request (by disposing my UnitOfWork, which in turn instructs the ActiveSessionManager to remove the current ISession from the RequestState) @Kurt

the ActiveSessionManager class (found here: http://davybrion.com/blog/2009/12/using-nhibernate-in-your-service-layer/) uses the RequestState to store and retrieve the NHibernate ISession instance for the current request.

You create the ISession instance at the beginning of the request (in my case, through the construction of my UnitOfWork), and you get rid of it at the end of the request (by disposing my UnitOfWork, which in turn instructs the ActiveSessionManager to remove the current ISession from the RequestState)

]]> By: kurt schroeder http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-31927 kurt schroeder Sun, 14 Mar 2010 15:41:46 +0000 http://davybrion.com/blog/?p=857#comment-31927 without needing to be said, "Yes I am still playing catchup on many concepts" without needing to be said, “Yes I am still playing catchup on many concepts”

]]> By: kurt schroeder http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-31679 kurt schroeder Fri, 12 Mar 2010 18:56:09 +0000 http://davybrion.com/blog/?p=857#comment-31679 In the case of storing/retreaving an NHibernate session i'm not sure where and how it is supposed to be stored. I have a class called RequestState, but have not progressed past this point. This is actually in reference to the yup above. I agree with Chuck, "Good stuff. Learning lots". After spending a fair amount of time on this i have learned a lot even today. That said, it's time to ask for a little help How does the session state for NHibernate get stored. Appreciated. KES In the case of storing/retreaving an NHibernate session i’m not sure where and how it is supposed to be stored. I have a class called RequestState, but have not progressed past this point. This is actually in reference to the yup above. I agree with Chuck, “Good stuff. Learning lots”. After spending a fair amount of time on this i have learned a lot even today. That said, it’s time to ask for a little help How does the session state for NHibernate get stored.

Appreciated.
KES

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-10040 Davy Brion Tue, 17 Mar 2009 22:07:55 +0000 http://davybrion.com/blog/?p=857#comment-10040 "Would the IRequestState be used in the ActiveSessionManager class to replace the field called “current?” " yup :) and yeah, you could definitely use a Dictionary-based TestRequestState implementation for your tests “Would the IRequestState be used in the ActiveSessionManager class to replace the field called “current?” ”

yup :)

and yeah, you could definitely use a Dictionary-based TestRequestState implementation for your tests

]]> By: Chuck http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-10039 Chuck Tue, 17 Mar 2009 22:01:57 +0000 http://davybrion.com/blog/?p=857#comment-10039 Davy - Just catching up on your post. Does this tie into your unit of work article? Would the IRequestState be used in the ActiveSessionManager class to replace the field called "current?" I was thinking that for testing, I would have an Implementation of IRequestState that did not depend on HttpContext. In order to keep with the IRequestState interface, it seems like I would need to use something like a Dictionary. Does that sound right? Good stuff. Learning lots. C Davy –

Just catching up on your post. Does this tie into your unit of work article? Would the IRequestState be used in the ActiveSessionManager class to replace the field called “current?”

I was thinking that for testing, I would have an Implementation of IRequestState that did not depend on HttpContext. In order to keep with the IRequestState interface, it seems like I would need to use something like a Dictionary. Does that sound right?

Good stuff. Learning lots.

C

]]> By: Dew Drop – January 17, 2009 | Alvin Ashcraft's Morning Dew http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7880 Dew Drop – January 17, 2009 | Alvin Ashcraft's Morning Dew Mon, 19 Jan 2009 12:26:04 +0000 http://davybrion.com/blog/?p=857#comment-7880 [...] Abstracting Request State (Davy Brion) [...] [...] Abstracting Request State (Davy Brion) [...]

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7878 Davy Brion Mon, 19 Jan 2009 11:35:42 +0000 http://davybrion.com/blog/?p=857#comment-7878 ah ok, i also thought it worked but i know that Ayende recently did some work on TransactionScope in the trunk so i wasn't sure... i think those changes were mostly MSDTC related though ah ok, i also thought it worked but i know that Ayende recently did some work on TransactionScope in the trunk so i wasn’t sure… i think those changes were mostly MSDTC related though

]]> By: Steve Degosserie http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7876 Steve Degosserie Mon, 19 Jan 2009 11:33:57 +0000 http://davybrion.com/blog/?p=857#comment-7876 It works, I've tested in the past (if my memory is not failing me lol) ... not sure if ISession is fully memory-transactional yet though (but that is rarely usefull anyway, you're usually supposed to throw away your ISession instance in case of a Tx Rollback). It works, I’ve tested in the past (if my memory is not failing me lol) … not sure if ISession is fully memory-transactional yet though (but that is rarely usefull anyway, you’re usually supposed to throw away your ISession instance in case of a Tx Rollback).

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7875 Davy Brion Mon, 19 Jan 2009 11:26:44 +0000 http://davybrion.com/blog/?p=857#comment-7875 yes, i'm talking about a WCF service layer i guess i could use WCF's transactional options, but so far this custom UoW approach is working pretty good so i'm not just going to change it. btw, NHibernate does have support for TransactionScope (although that might just be in the current trunk, not sure about that) so what you're doing should work as well yes, i’m talking about a WCF service layer

i guess i could use WCF’s transactional options, but so far this custom UoW approach is working pretty good so i’m not just going to change it.

btw, NHibernate does have support for TransactionScope (although that might just be in the current trunk, not sure about that) so what you’re doing should work as well

]]> By: Steve Degosserie http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7874 Steve Degosserie Mon, 19 Jan 2009 11:20:26 +0000 http://davybrion.com/blog/?p=857#comment-7874 Hello Davy, So your custom UoW starts NH transaction when you enter your service layer ... when you say 'service layer', are you talking about your WCF services, or another logical service layer below your WCF services ? if WCF service layer, why not use the transactional options of WCF over your custom implementation? What I'm usually doing is have an interceptor on my Business Layer to start transactions that nest with the ones from the (WCF) service layer (if any) ... that's where System.Transactions TransactionScope come in handy ... but that implies that the underlying ORM used must support TransactionScope. Hello Davy,

So your custom UoW starts NH transaction when you enter your service layer … when you say ’service layer’, are you talking about your WCF services, or another logical service layer below your WCF services ? if WCF service layer, why not use the transactional options of WCF over your custom implementation?

What I’m usually doing is have an interceptor on my Business Layer to start transactions that nest with the ones from the (WCF) service layer (if any) … that’s where System.Transactions TransactionScope come in handy … but that implies that the underlying ORM used must support TransactionScope.

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7871 Davy Brion Mon, 19 Jan 2009 09:50:05 +0000 http://davybrion.com/blog/?p=857#comment-7871 the UoW implementation is probably very similar to other ones i didn't really say that TransactionScope isn't useful, just that i don't use it :) the only reason why i don't use it is because i just stick with the transactions that NHibernate provides me with, and that works well for me the UoW implementation is probably very similar to other ones

i didn’t really say that TransactionScope isn’t useful, just that i don’t use it :)

the only reason why i don’t use it is because i just stick with the transactions that NHibernate provides me with, and that works well for me

]]> By: Andy Pook http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7870 Andy Pook Mon, 19 Jan 2009 09:14:12 +0000 http://davybrion.com/blog/?p=857#comment-7870 And that uses the same technique to ensure you always get the correct ambient transaction? I assume that your custom UoW is similar to others out there? Giving nestable transaction scope, rollback, commit etc. You intimate that TransactionScope isn't useful. What, essentially, do you see as the benefit of a custom UoW over TransactionScope? And that uses the same technique to ensure you always get the correct ambient transaction?
I assume that your custom UoW is similar to others out there? Giving nestable transaction scope, rollback, commit etc.
You intimate that TransactionScope isn’t useful. What, essentially, do you see as the benefit of a custom UoW over TransactionScope?

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7828 Davy Brion Sun, 18 Jan 2009 17:21:10 +0000 http://davybrion.com/blog/?p=857#comment-7828 i indeed use NHibernate I basically start a transaction whenever i enter my service layer, and everything that happens from then on is managed by the parent transaction. I can call any piece of code knowing that everything that gets executed can be committed or rolled back by the parent transaction. I use a custom Unit Of Work implementation for this. i indeed use NHibernate

I basically start a transaction whenever i enter my service layer, and everything that happens from then on is managed by the parent transaction. I can call any piece of code knowing that everything that gets executed can be committed or rolled back by the parent transaction. I use a custom Unit Of Work implementation for this.

]]> By: Andy Pook http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7826 Andy Pook Sun, 18 Jan 2009 17:12:52 +0000 http://davybrion.com/blog/?p=857#comment-7826 violated: Sure, as far as the clr runtime spec is concerned. But then ThreadStatic is, as you've discovered, pretty broken in asp anyway. (unless you really know where asp async method may not complete synchronously). TransactionScope: I assume from your comment that you use some ORM (NHibernate etc). Have you no need for ambient transaction/session to be able to compose various actions coded in separate methods/classes? violated: Sure, as far as the clr runtime spec is concerned. But then ThreadStatic is, as you’ve discovered, pretty broken in asp anyway. (unless you really know where asp async method may not complete synchronously).

TransactionScope: I assume from your comment that you use some ORM (NHibernate etc). Have you no need for ambient transaction/session to be able to compose various actions coded in separate methods/classes?

]]> By: Davy Brion http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7818 Davy Brion Sun, 18 Jan 2009 11:29:54 +0000 http://davybrion.com/blog/?p=857#comment-7818 if they were to migrate the ThreadStatic values for us, it would appear to work correctly but it would be a pretty ugly hack where the whole concept of ThreadStatic is pretty much violated :) dunno about TransactionScope though... haven't used that in a while :) if they were to migrate the ThreadStatic values for us, it would appear to work correctly but it would be a pretty ugly hack where the whole concept of ThreadStatic is pretty much violated :)

dunno about TransactionScope though… haven’t used that in a while :)

]]> By: Andy Pook http://davybrion.com/blog/2009/01/abstracting-request-state/comment-page-1/#comment-7817 Andy Pook Sun, 18 Jan 2009 11:25:36 +0000 http://davybrion.com/blog/?p=857#comment-7817 This comes up every so often (ASP.Net thread agility). Ayende has a class (as you'd expect!!) called LocalData in Rhino.Commons that does something similar (but doesn't cover the WCF scenario). I and many others have our own various solutions. There are 2 questions that I always have with this: 1. if this is such a problem in ASP. Why doesn't the ASP runtime do that magic to migrate the thread statics for us? It must do something similar to make HttpContext.Current migrate. 2. How does TransactionScope work? Internally it seems to use a ThreadStatic in a helper class called ContextData. The answer to 1. is... That's just the way it is, we'd best just get on with it! The answer to 2. is unclear. Does this also fail in the high load ASP scenario or is there some other magic I'm not seeing that we can borrow instead of many different wheels? --Andy This comes up every so often (ASP.Net thread agility).
Ayende has a class (as you’d expect!!) called LocalData in Rhino.Commons that does something similar (but doesn’t cover the WCF scenario). I and many others have our own various solutions.

There are 2 questions that I always have with this:
1. if this is such a problem in ASP. Why doesn’t the ASP runtime do that magic to migrate the thread statics for us? It must do something similar to make HttpContext.Current migrate.
2. How does TransactionScope work? Internally it seems to use a ThreadStatic in a helper class called ContextData.

The answer to 1. is… That’s just the way it is, we’d best just get on with it!
The answer to 2. is unclear. Does this also fail in the high load ASP scenario or is there some other magic I’m not seeing that we can borrow instead of many different wheels?

–Andy

]]>