Creating an Alert System with NHibernate, WCF and MSMQ

For a project that I am working on we needed to create an alert system. This system alerts the user about certain changes in the database via email or text. When I started googling for an alert system, nothing relevant came up. But then trying to solve another problem I came across two very interesting posts.

- Manuel Abadia's ASP.NET stuff - NHibernate and calculated properties
- SOA'izing MSMQ with WCF (and Why It's Worth It)

Using these two posts we were able to create a subscriber based alert system. For our solution we created a marker interface IAlert and have all domain objects we needed to alert on inherit from this interface. Instead of using the FindDirty method as mentioned in the first post, we used OnSave [for Insert], OnFlushDirty [for Update] and OnDelete [for delete]. In these functions we place a check if the object is of type IAlert we converted its current and previous state if any into an xml packet. Then that packet was saved on the HttpContext.Current.Items collection. The reason for saving it on the Items collection is that transaction could fail and we don’t want to generate alerts for failed transactions. Then in the PostFlush method in the interceptor we called the WCF service that places that xml packet on to the MSMQ queue. This operation is asynchronous and does not add time to the transaction. On the other side we wrote a WCF service that processes that packet. This way, alert was sent asynchronously and transaction time was not effected. Another advantage of using this approach is processing WCF service has all the information needed to process that alert in the xml packet and only needs to hit that database when it needs to gets that list of subscribers to send messages.

Context Based Sessions in NHibernate

I have seen a lot of people asking questions about creating context based Sessions in NHibernate. One of the solutions that people have suggested is to create a new Session Factory for each database. This solution sounds attractive, but will become problematic as the application scales up. In this post I would to share my solution that we implement in my current project.

NHibernate lets the developer provider their own ADO.net connection. As we were using Open Session in View strategy we decided to pass the connection string to create a session using ISessionFactory. OpenSession(IdbConnection obj). By using this technique NHibernate’s second level cache is disabled. For our application we were not interested in using a second level cache so it didn’t matter. If you are interested in using second level cache solution is to implement your own IConnectionProvider. Information about which database to use can be passed using HttpContext.Items.

NHibernate context is feature that is very rarely talked about. NHibernate Session Factory provides a method GetCurrentSession() this lets you get current session in the context. NHibernate provides built in implementation for web application. For more information please review section 2.3 of NHibernate documentation. This way the DAO and Business Object don’t have to worry about how to create the session and remain agnostic of which database they are connecting to.



Please comment. Thanks