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
