Reputation: 1841
Is there any mileage in pooling NHibernate sessions for read-only operations? Where a system is doing a lot of reads and only a few writes would it make sense to create a pool of sessions that get reused for the purpose of reading data and only open a new session when you explicitly have to commit changes?
My thinking, for what it's worth, is that if you got say 1000 requests in a minute to read data. If those reads were short lived in terms of miliseconds, a pool of sessions (say 3) could probably handle them all instead of having to create and dispose of 1000 sessions.
Upvotes: 2
Views: 575
Reputation: 17350
Your thinking is applicable to database connections which are already pooled, you don't need to do anything special, it is enabled by default.
NHibernate Session is not equal to database connection. Session is NHibernate's implementation of Unit of Work pattern. Pooling Units of Work can be dangerous because each Unit of Work holds on to all the objects it had loaded (for change tracking purposes) so they can not be garbage collected. Even if you clear the UOW before returning it to pool - there is no point because creating UOW/ISession is cheap, it does not allocate database connection.
Take a look at this answer if you want to optimize memory consumption with NHibernate.
Upvotes: 2
Reputation: 30813
creating and disposing sessions is very light weight and connections are handled by the connectionpool. IMO there is no benefit of using session pooling. It has one drawback as it holds every loaded object in the session cache which could be a memory leak and performance hit if the session is reused.
Upvotes: 2