Hello Hibernators,

once again, i have to raise the question regarding the session stuff - this time not about how to handle (in code) the ISession with ASP.NET but about the question:
why should my application use more than one session?

I know:
if an application is complex, with transactions, multiple users accessing the same data at the same time etc., then you need more than one session - but, what if your application is just simple, like a forum? A forum, where the users can only read information from the DB and where they can edit only their own/private data (like password)?
Is there any need to use more than one session object?

Any comments on that?

Regards

If the application is simple enough (does not need to take advantage of object oriented concepts such as inheritance-composition etc...), maybe the question needs to be "Should I use NHibernate for this application or just out-of-the-box ADO.Net?"

If the answer is YES then here are some things to think about when considering your strategy for managing sessions/transactions...

Sessions Timing out...
Let's supposed your application is 'simple' with few users. Sessions tend to expire when they sit idle so you would need to detect if the site is inactive for a long enough period to reconnect the session.

Database fail-overs
Many database are implemented with fail-over systems. So your database connection may require a reconnect of the db server fail-over is executed..

Database Locking
Many databases implement different types of locking strategies on tables, rows, etc...
Having sessions connect for long periods of time could actually have these locks on rows/tables for a long period of time which could affect performance and concurrency...

Unexpected Database Server/Network Issues
There are times when the network and/or database drops connections so your site would have to detect this since the same session is used across multiple requests...
One session per request would eliminate this as only the active request would be affected...

Implementing a second-level cache also allows you to optimize your round-trips to/from the database in a mostly read-only system...

Correct me if I'm wrong but I believe most of the ADO.Net Data Providers provide connection pooling so there isn't any extra overhead introduced by logging into the DB all the time..

Database best-practices are to have as short as possible sessions and as short as possible transactions against the database...

Also ASP.Net is multi-threaded so you may issues attempting to use the same session across multiple threads... I usually make sure my Sessions are thread-safe and fire up a new session for each asp.net request....

Just some of my thoughts on the matter...

Greg

hi gcook1@shaw.ca,

thanks for your reply!

to your question:
ORM is not essential to this application, yes, but it's nice and i like it working with a database-server without having to write in SQL :)

all your points are sounding very logical to me! i will change the app, even if its a simple one (max. 10 - 15 users) - it gives me a better feeling knowing that everything is programmed "correctly".

do you or someone else know a good tutorial where it is demonstrated how to use the ISession correctly for "large scale apps"?

regards