What is a better aproach of using session ? closing it after a transaction or retaining a single session through out the application. Currrently i am having a single session but i can only open 30 instances of the application at one time. Can it be a setting with DB2 or should i close the session after every transaction (or set of transactions)?
It again depends on how you want your model to be available. As you know, hibernate session is the first level cache. If you want to operate on a set of data, which is attached to a request/transaction session scope, then when the request/transaction perishes so does your session data.
If you have it for the whole application, then every request need not fetch the data from the Database.
It really depends on what kind of application you run, what is the freshness of data" you need to have, etc.,
should i close the session after every transaction (or set of transactions)?
- you need not. you can actually choose to flush the session after many transactions.
[ September 26, 2007: Message edited by: Arun Kumarr ]
Freshness of data doesn't matter much, as i just read a few arguments from database & do some xml stuff show result on screen & user submits the result in new table.
I am not using any mapping (one-to-one etc) as well. but the only concern is performance as in what makes application faster working in one session or closing the session & reopening it when required. Not only for 1 application instance but overall for all instances running in parallel.
I changed some settings in DB2 so now i am not restricted to only 30 conections so that problem is solved.
but the only concern is performance as in what makes application faster working in one session or closing the session & reopening it when required
The session is a lightweight object. Opening and closing it is a trivial operation. Caching data in memory is liable to improve performance, so you could keep a session open to do this (since the session acts as a cache). It all depends on how tolerant your requirements are to potentially dirty data; does it matter that the users are seeing out of data data or not? Do users ever need to see the data updates the user is submitting?
Actually i am currently working on 2 swing application.
1st application : There would be only 1 user, just to upload some data(once in a month stuff). I do need to show the updated records but there is only one user so i don't think there is much possibilty of dirty data.
2nd application : Many user (more than 100) would be accessing the Database but i don't need to show them updated stuff. but with each session one connection is occupied so i fear to run out of maximum number of application connecting to DB.
What i understood is that i should keep one session for the first one as i need to read a lot of stuff from the database(it would be faster to have them in cache). For the second one i should close the session & reopen as even if users forgets to close the application, i don't run out of max. number of connections.
I suggest you can try any third party JDBC connection management libraries. Like c3p0 or proxool, as the hibernate documention suggests.
If you are worried about session opening and closing, you can use HibernateTemplate which removes the worry off the developer to remember to close sessions.
What i understood is that i should keep one session for the first one as i need to read a lot of stuff from the database(it would be faster to have them in cache).
It should be quicker, assuming your client has enough memory to support the volume of data you want to cache. If they don't, or its nearing the limit it will be slower.
For the second one i should close the session & reopen as even if users forgets to close the application, i don't run out of max. number of connections.
Session does not equal Connection! If you use connection pooling many sessions may be using only one phisical connection.
Is performance the only driver for your design? If it is, I'd rethink your approach. Do you know that session per transaction will perform too poorly at this point? If your implement your applciation to use a Session per transaction then performance test it you may well find it performs well enough. If you properly layer your architecture, it shouldn't we too dificult to rework it to use a different Session management model if this becomes necessary. Its a bad idea to go with a gut instinct of what may be more performant early on in the design; early optimisations are often the root of bad designs. Prototype your app. and test it. See which is better for your specific circumstances.