I need some insights and thoughts about a refactoring I'm about to do to our web-app.
We initially used the session-per-request pattern with NHibernate and ActiveRecord by using the On_BeginRequest / On_EndRequest in the HttpApplication to create and dispose the session. Later on, we realized that any DB-related exceptions got thrown outside of our monorail-context, meaning that our rescues didn't kick in. As another sideeffect, we didn't have the option to fully skip creation of NHibernate sessions in any action, which in some cases would be desirable.
So we rewrote it to create sessions in Initialize() / Contextualize() in our base controller, and disposed them in the Dispose() of our base controller. We also Rollback the session in our rescue controller to prevent any half written changes to the DB. So far, so good. The reason for doing it in the Dispose() is because we want it to live through the view-rendering, because of lazy-loading reasons aswell as viewcomponents that needs to get a session (we could switch to units-of-work for the viewcomponents, but they don't seem to have a Dispose()...)
However, I'm experiencing some deadlock issues where we have started transacations in the DB that isn't getting rollbacked nor committed and I can't get my head around it, mostly because of the mess we've made with this approach...
So I found this article: http://hackingon.net/post/NHibernate-Session-Per-Request-with-ASPNET-MVC.aspx
And I thought, "Filters, we can use that in MonoRail too!", because it can kick in on BeforeAction and AfterRendering.
My questions then are:
What happens if an Exception occurs in the filter?
Will AfterRendering fire even if an Exception occurs in the action or the rendering?
Would you recommend this approach, if not, what are your suggestion instead?
Any pointers are very much appreciated!
You need an application error handler to care of exception handling.
Attach a debugger and find out.
Probably not (even though it is my article). It doesn't work with RenderAction. Best to use an IoC container to control the lifetime of connections.
Related
I was wondering if we can some how extend NHiberate to throw an exception if a piece of code attempted to save an object to a database without beginning a transaction? Since beginning a transaction is a requirement for calling Save() to work properly, I can't see a programmer calling Save() without beginning a transaction in the first place.
Solution is not in the exception throwing. It is about keeping us (developers on the project) aware of what and where we are doing
1) Project shared approach. Firstly, explain to the team how the Architecture of application works. All team members should now, that Unit of Work, or Session per Request patterns are in place.
2) The FlushMode. Secondly, explain the concept of the Session object. ISession. Save() or Update() is far away from SQL execute INSERT or UPDATE. What count is the ISession.Flush(). And (based on the first step) we can decide when that Flush() happens.
I would suggest setting the FlushMode to on Commit or None (with explict call). And then, if a team member would like to Execute any write command - one standard place, one common way (used on the project) will guide hin/her.
The call Session.Flush() should/will/must be wrapped in a transaction.
I have a strange behaviour which I can't find any solution for days..
The behaviour I experience is the classic LazyInitializationException with no session or session was closed
which is usual when there's no contextual session and trying to access lazy loaded properties/collections, but this in not my case because I have:
Session-per-request session bounded with Spring.NET OpenSessionInViewModule
A session opened and bounded to the context (web request)
Entities with collection as "list" (mapping list collection) with lazy="extra" or with "set" (mapping set collection) (The issue is caused mainly with lazy=extra..)
It seems that the Count statement for extra cound be done, but accessing the whole collection throws the exception
After investigating the usual issues:
no session opened
the object is not bounded to any session
a call to Session.Clear or Session.Evict was made (so any lazy for the evicted instance will work)
the Spring.NET WebSupportModule is not registered
I found no explicit reasons of why this happen..
A strange behaviour is if I profile in NHprof, I see the exception in a new session, in other words, the contextual session works correctly,
but when the exception is thrown, that exception is visualized in a secondary session.. but NO code open a session, and a single, contextual session
is opened..
Anyone knows what other reasons could cause a situation like that?
Thanks in advance
It's difficult to diagnose without seeing some code, but the problem sounds very similar to this. In the linked case OpenSessionInView was being used in addition to setting the session context in another location (similar to your first two bullet points) and WebSupportModule was not registered (as in your last point).
On the other hand, I know nothing about Spring.NET.
What would I need to be doing wrong to get an aggregate to be returned from the session (loading by id) that is an empty instance of the aggregate and not the entire graph. When I hit the actual url that is requested in my browser I see the full json object, hence, why I am suspicious of my session management.
I have tried recreating the situation in unit tests but no manner of poor session management can recreate what I am seeing. I see some null instances returned but never this strange 'empty' instance - which has an id but none of the properties have been hydrated.
I am seeing this behaviour in unstable build 438.
I just checked the behaviour by executing a query and am seeing the same issue, so it is not just when calling Load()
If you are seeing symptoms similar to those that I presented in the original question - the most likely scenario is that you are loading the entity via a 'stale' session.
I discovered that due to some IoC container config flaws on my behalf (remember, singletons are bad kiddies) that I was attempting to load via a session that had been hanging around far too long. I can't determine whether it had been disposed or not (I suspect not) but it was definitely living well past its creation date.
I am not sure this exactly explains the behaviour I was seeing, but I present it here in the hope of helping others.
I came across a very strange problem which never happened to me before.
In the login code:
var sqlLogin = db.LoginRetrieve(loginID, archived).SingleOrDefault();
//(db is the linq data context)
--problem:
If two users login at the same time, this line of code will throw an exception which is "The required column 'UserLoginID' does not exist in the results."
But if a single user logs in or two users don't click the button at the same time, it will have no exception.
Is there anyone can share some lights on this? Thanks in advance.
Han
I suspect that your DataContext is shared between requests.
Don't do that.
You should create a separate DataContext for each request.
Otherwise, you'll get nasty threading issues like this one. (DataContext isn't thread-safe)
In general, you should be very careful when sharing objects between requests (eg, statics or Application / Session state).
Unless you know specifically otherwise, you should assume that the object is not thread-safe and cannot be shared.
I'd like to ensure, that when I'm persisting any data to the database, using Fluent NHibernate, the operations are executed inside a transaction. Is there any way of checking that a transaction is active via an interceptor? Or any other eventing mechanism?
More specifically, I'm using the System.Transaction.TransactionScope for transaction management, and just want to stop myself from not using it.
If you had one place in your code that built your session, you could start the transaction there and fix the problem at a stroke.
I haven't tried this, but I think you could create a listener implementing IFlushEventListener. Something like:
public void OnFlush(FlushEvent #event)
{
if (!#event.Session.Transaction.IsActive)
{
throw new Exception("Flushing session without an active transaction!");
}
}
It's not clear to me (and Google didn't help) exactly when OnFlush is called. There also may be an implicit transaction that could set IsActive to true.
If you had been using Spring.Net for your transaction handling, you could use an anonymous inner object to ensure that your DAOs/ServiceLayer Objects are always exposed with a TransactionAdvice around their service methods.
See the spring documentation for an example.
To what end? NHProf will give you warnings if you're not executing inside a transaction. Generally you should be developing with this tool open anyway...