Multiple "application transactions" per session?

mchyzer · **Joined:** Sat Jul 17, 2004 5:16 pm **Posts:** 143

When I read the last few paragraphs of this document, I get confused:

http://www.hibernate.org/168.html

It says "Don't use the same Session for multiple application transactions". I understand what this means (as long as it means serial transactions and not concurrent transactions :) ), but I do not understand why. Before I got to this part in the article, and since my apps have mainly "application transactions", I wanted to assign the Hibernate Session to the J2EE session (and give back DB connections at the end of each request), and open and close Hibernate transactions when I have new application transactions. So why do I need to close the session and open another right after?

Here's what I thought was ok, though now it seems like it is not (no big deal, I can close Sessions, but Im just wondering if this article is correct).

Code:

SessionFactory factory = cfg.buildSessionFactory();
Session s = factory.openSession();
Transaction tx= s.beginTransaction();

//first application transaction that spans multiple J2EE Requests

tx.commit();

tx= s.beginTransaction();

//second application transaction that spans multiple J2EE Requests

tx.commit();

//etc.

s.close();

Thanks, Chris

anthony · **Posted:** Mon Jul 19, 2004 4:20 am

if you know exactly how to handle this design, you can use it.
You must know that many :
- httpRequest for one httpSession (i suppose you are storing the hibernate session somewhere via httpSession) is always possible (refresh IE F5),
- and that hibernate session isn't threadsafe
- what happens if a user go away take a coffe? his httpSession keeps living, it stores hibernate session which is linked to a jdbc connection and so:
* when he comes back, the timeout is thrown and you get an exception
* if you have chance, you don't have timeout but the pool isn't very usefull since users never release the connections....
so there is a risk!
You can exactly have the same behaviour using threadlocal pattern, extremely usefull and more secure

mchyzer · **Joined:** Sat Jul 17, 2004 5:16 pm **Posts:** 143

Im not trying to argue, I just didnt understand the line in the document

Quote:

"Don't use the same Session for multiple application transactions"

I guess for now I will assume that this means multiple transactions at the same time, and not serial (see my code post above)

anthony wrote:

- what happens if a user go away take a coffe? his httpSession keeps living, it stores hibernate session which is linked to a jdbc connection and so:

I was going to have a J2EE session listener which would close the Hibernate session. Also, at the end of each J2EE request, have a request listener which gives the JDBC connection back from the Hibernate session so the JDBC connections arent idle and unused

anthony wrote:

You can exactly have the same behaviour using threadlocal pattern, extremely usefull and more secure

I dont know how using the ThreadLocal object would help me here. Since I want a session attached to a J2EE session, not the thread (which could be servicing multiple people).

OK, so unless someone tells me otherwise, I will go forward with 1 Hibernate session linked to the user's J2EE session, and never restarting the Hibernate session midway through the J2EE session. Thanks, Chris

steve · **Posted:** Tue Jul 20, 2004 10:08 am

Application transaction = unit of work

Thus, the doc is saying to not reuse a session across distinct units of work. Why? Because you *will* get stale data using this approach. The hibebernate session acts as the first-level cache in hibernate's dual-layer caching. Use it and then close it as soon as possible (or at least keep clearing it).

Quote:

Since I want a session attached to a J2EE session, not the thread (which could be servicing multiple people).

This is *extremely* bad. A user's http session may last hours. And the hibernate session associated to that user (and http session) may have data that is as old as this http session.

mchyzer · **Joined:** Sat Jul 17, 2004 5:16 pm **Posts:** 143

Good, thanks for the explanation.

We have pretty much only application transactions that are several screens, but perhaps with many objects that I do not want to have to reattach to the next session on the next button click. So maybe I can keep the session with the J2EE session, and each time the transaction is committed (which should be infrequent), we will close the session and transaction and make a new one (we are wrapping our J2EE framework around Hibernate so we can control this). See any issues with this? Thanks again, Chris

anthony · **Posted:** Tue Jul 20, 2004 12:40 pm

Quote:

I do not want to have to reattach to the next session

you have to choose what you want or what should be done!

imagine:
User A/ SessionA UserB/ SessionB
| |
| |
get Object obj |
| |
| get Object obj
| |
| delete obj commit
|5 minutes later |
update obj
you have stale data
pouf pouf exception
all work done by user A is lost

do you understand why it is better to have 1session per unit of work (generally request)?

mchyzer · **Joined:** Sat Jul 17, 2004 5:16 pm **Posts:** 143

Good. This is exactly the behavior that we want. Since our apps are usually:

1. View data screen
2. Change data screen
3. Confirm screen
4. Commit data and done screen

This works perfectly (if the data is updated after the view but before the commit we want an exception). We are migrating to Hibernate from OJB which did not solve this problem, so it is nice to have the OR framework take care of this. Thanks!