[hibernate-dev] Integrating new transaction work.

[Max Rydahl Andersen]

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 <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
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

/max
http://about.me/maxandersen