[hibernate-dev] Integrating new transaction work.
Steve Ebersole
steve at hibernate.org
Thu Mar 3 11:44:10 EST 2011
I have run across a few decisions while integrating the new transaction work.
The first 2 are descisions I made while developing the new code that I wanted
to get some feedback on.
-----------------
1) Transaction instances are no longer reusable. The impact here is that code
such as the following would no longer be valid:
Transaction t = session.getTransaction();
t.begin();
...
t.commit();
t.begin();
...
t.commit();
However, this is still valid:
session.getTransaction().begin();
...
session.getTransaction().commit();
session.getTransaction().begin();
...
session.getTransaction().commit();
As is:
Transaction t = session.getTransaction();
t.begin();
...
t.commit();
t = session.getTransaction();
t.begin();
...
t.commit();
Or even:
Transaction t = session.beginTransaction();
...
t.commit();
t = session.beginTransaction();
...
t.commit();
-----------------
2) Subsequent begins() are no longer allowed. This has always been a pet-
peeve of mine that code such as this is perfectly valid:
Transaction t = session.getTransaction();
t.begin();
...
t.begin();
t.begin();
t.begin();
...
t.commit();
What is included in the commit?
-----------------
3) disconnect/reconnect chaining. This is really only important in cases of
user-supplied connections[1] (in fact we should probably disallow disconnect
and reconnect unless that is the case). It is meant to disconnect the session
from the underlying JDBC connection and later reconnect it (generally speaking
the use case here is serialization in say conversations).
Today we allow disconnection of a Sesson that currently has an active
transaction in such a way that the transaction remains valid. So I see 2
potential clarifications to this behavior (in both cases lets assume we
disallow disconnect if the connection is user-supplied):
a) disallow the disconnect if the Session currently has an active transaction
b) implicitly commit any current trasaction on disconnect.
Personally I am not a fan of (b) for the simple fact that I am not sold that
the natural follow up of automatically beginning a transaction on reconnect
makes sense.
(a) would look like:
Session s = sf.openSession(connection);
s.beginTransaction();
..
s.getTransaction().commit(); // generally manual flush mode
connection = s.disconnect();
...
s.reconnect(connection);
s.beginTransaction();
...
s.flush();
s.getTransaction().commit();
Note that in the non-user-supplied case, the disconnect and reconnect are
implicit as a natural part of the transaction lifecycle due to connection
release modes.
-----------------
[1] SessionFactory.openSession(someConnection)
---
Steve Ebersole <steve at hibernate.org>
http://hibernate.org
More information about the hibernate-dev
mailing list