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(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev