[hibernate-dev] Integrating new transaction work.

[Emmanuel Bernard]

1. I think I'm fine with that. I never really trusted Hibernate to properly implement this anyways :)
2. is there a isStarted() method or something equivalent for someone to guard against subsequent begin calls?
3. I am neutral. I tend to like b for it's simplicity but a would not bother me much.

On 3 mars 2011, at 17:44, Steve Ebersole wrote:

> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev