Thanks for the heads up. Nice with some real examples also :-) On Thu, 03 Mar 2011 17:44:10 +0100, Steve Ebersole <st...@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 <st...@hibernate.org> > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
