On Mar 4, 2011, at 18:02, Emmanuel Bernard wrote: > 1. I think I'm fine with that. I never really trusted Hibernate to properly > implement this anyways :)
Was nested transactions actually ever possible ? (i know some weird databases support it...just wondering if anyone actually used it ;) btw. will it fail hard ? > 2. is there a isStarted() method or something equivalent for someone to guard > against subsequent begin calls? same thoughts. And what will actually happen if users does reuse the TX ? will it blow up with a sensible error? > 3. I am neutral. I tend to like b for it's simplicity but a would not bother > me much. b is evil - its like Oracle's jdbc connection.close() that commits the transaction...evil. a sounds fine but I'm curious how you would go about implement the multiple sessions on one transaction to do the "audit-interceptor" pattern in this new world? /max > > 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 <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 /max http://about.me/maxandersen _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
