[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