i rely on IDisposable quite heavily, so i make sure that disposable instances are disposed properly, but that’s about it

as long as you don’t keep references alive somewhere, i don’t think there will be any benefit from explicitly clearing your request state

What are your thoughts w.r.t cleaning up the Request State? Do you prefer just leaving it for the GC to take care of? I see there is an OperationContext.OperationCompletedEvent that you can hook into should you need to do some RequestState cleanup. What do you think?

Carel

i host most of my WCF services in IIS, and then i indeed perform all the IOC wiring in global.asax

Thanks.

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)

Appreciated.
KES

yup

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

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

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

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.

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

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.

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?