[hibernate-dev] Integrating new transaction work.

[Hardy Ferentschik]

Thanks for the heads up.
Nice with some real examples also :-)

On Thu, 03 Mar 2011 17:44:10 +0100, Steve Ebersole <steve at hibernate.org>  
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