I'm developing and application that runs as a Windows service. There are other components which include a few WCF services, a client GUI and so on - but it is the Windows service that access the database.

So, the application is a long-running server, and I'd like to improve its performance and scalability, I was looking to improve data access among other things. I posted in another thread about second-level caching.

This post is about session management for the long-running thread that accesses the database. Should I be using a thread-static context? If so, is there any example of how that would be implemented.

Every one around the net who is using NHibernate seem to be heavily focussed on web-application style architectures. There seems to be a great lack of documentation / discussion for non-web app designs.

At the moment, my long running thread does this:

  1. Call 3 or 4 DAO methods
  2. Verify the state of the detached objects returned.
  3. Update the state if needed.
  4. Call a couple of DAO methods to persist the updated instances. (pass in the id of the object and the instance itself - the DAO will retrieve the object from the DB again, and set the updated values and session.SaveOrUpdate() before committing the transaction.
  5. Sleep for 'n' seconds
  6. Repeat all over again!

So, the following is a common pattern we use for each of the DAO methods:

  • Open session using sessionFactory.OpenSession()
  • Begin transaction
  • Do db work. retrieve / update etc
  • Commit trans
  • (Rollback in case of exceptions)
  • Finally always dispose transaction and session.Close()

This happens for every method call to a DAO class. I suspect this is some sort of an anti-pattern the way we are doing it.

However, I'm not able to find enough direction anywhere as to how we could improve it.

Pls note, while this threa

nhibernate
Edit
Report