We are using Castle Windsor as our IoC Container in ServiceStack. The ServiceStack service implementation is used in a self hosted environment (integration tests) as well as in a IIS hosted environment (production), both using the same Windsor configuration. Therefore using the Windsor PerWebRequest lifestyle was not possible and I had to implement our own. I did so by implementing a Windsor IScopeAccessor that stores the Windsor scope in RequestContext.Instance.Items. So far so good.
The second requirement is an automatic unit of work that begins whenever a new request arises and commits when the request has been processed succesfully or rolls back if an error occurred. I implemented a plugin that makes use of the RequestFilter, ResponseFilter and UnhandledExceptionHandler hooks of ServiceStack to realize such an automatic unit of work. The plugin resolves the the unit of work object (e.g. the NHibernate session) via Castle Windsor.
Initially the custom scope accessor registered the Windsor scope for disposal with RequestContext.Instance.TrackDisposable(). However, as it turns out the requestcontext is disposed before the hooks are called. Therefore resolving the unit of work via CastleWindsor leads to strange effects. The disposing of the scope is now done in the unit of work plugin which is awful.
Are there any better ways to implement such an automatic unit of work? Are there equivalent hooks that are called before the request ends?
The last hooks that are fired at the end of a request are the AppHost.OnEndRequestCallbacks delegates which is fired by your AppHost.OnEndRequest() which you can also override, if you do, you’ll want to call base.OnEndRequest() and retain existing behavior.
Personally I’d avoid using Request Context, I find it unnecessary, less predictable and requires ugly framework coupling on thread static RequestContext instances. Having connection resource pooling enabled (default for SqlServer) ends up being better than Request Scoped connections as busy connection lifetimes are reduced. Other than that when you need to share any objects throughout the Request pipeline you can use IRequest.Items.
I see, thanks for the hint with OnEndRequestCallbacks. My intention for using request scoped components is that I would like to do all the work of a one request in one transaction. Therefore all components resolved for the same request need the same NHibernate session or the same unit of work in general. That is the rationale behind the custom Windsor scope.
In addition, the transaction should be automatically started at the begin of each request and committed / rolled back at the end of each request (depending on whether an error occurred). Therefore I would need to find out whether an error (i.e. unhandled exception) occurred in the OnEndRequest callback. Is this even possible in the callback?
As a general feedback: I totally love ServiceStack, but the documentation on this topic is a bit sparse. I had a hard time implementing even my hacky solution and I found many people having similar issues with ServiceStack, Castle Windsor and NHibernate.
The 2 handlers you can hook into to get notified about exceptions are IAppHost.ServiceExceptionHandlers for handling Exceptions for Service requests where the Request DTO is known and IAppHost.UncaughtExceptionHandlers for handling other errors.
The OnEndRequest is typically just used for signalling the end of any request but I guess you could look at the Response StatusCode to determine if the response was an error, e.g:
var wasError = request != null && request.Response.StatusCode >= 400;