ActiveRecord SessionScope
I have been spending some time trying to understand how Castle’s ActiveRecord manages SessionScopes for web applications. A SessionScope abstracts access to the database and manages a cache of conversions with the database (likely an oversimplified.) In a web application scenario it is best to ‘scope’ the SessionScope to a web request as this is the logically boundary of a single unit of work. I am interested in how this approach is superior than simply using an IOC container like Windsor with a PerWebRequest lifestyle.
Here is a bit of info about the classes involved in scoping SessionScope per web request for Castle’s web applications:
SessionScope
For the most part in ActiveRecord a SessionScope abstracts a NHibernate Session. provides access to current session. The injected FlushAction tells it what to do during disposal. Basically flush changes to the database or do nothing. The SessionScope also can get injected with a SessionScopeType (Simple, Transactional,…)
The static SessionScope.Current is basically support for service locating the current thread’s existing session if one is present. This mechanism uses ThreadScopeAccessor to manage a stack of SessionScopes for the current thread.
SessionScopeWebModule
This HttpModule manages scoping a SessionScope to a web page request. During the BeginRequest event a new SessionScope is created (non-transactional, auto flushing). The EndRequest event disposes the SessionScope which will flush changes out to the database.
Summary
I am guessing that the ActiveRecord developers do not want to have a dependency on a specific IoC container, so they baked in their own global memory mechanism. The sole thing I can find that is notably superior about the ActiveRecord SessionScope is that during the EndRequest event they automatically flush their SessionScope. I am guessing a similar tactic could be accomplished with a Facility in Windsor.
Note: The castle websites are currently down due to their office move.
