David
David

Reputation: 1841

NHibernate read only pool of sessions?

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

Answers (2)

Dmitry
Dmitry

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

Firo
Firo

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

Related Questions