[hibernate-dev] JdbcSession proposal

Steve Ebersole steve at hibernate.org
Fri Dec 6 13:07:22 EST 2013


So I'll get the ball rolling :)  Here is one thing in particular I was 
hoping to start a discussion on...

For JTA transactions we currently have a lot of complex logic to manage 
who "drives" the transaction flow into Hibernate (in terms of Hibernate 
reacting to the completion).  There are potentially 2 drivers:
1) A JTA Synchronization registered with the JTA system
2) The org.hibernate.Transaction instance

A lot of the complexity in our current code comes from the fact that we 
have a lot of attempting to handle cases in which the JTA 
Synchronization cannot be registered.  So one of the simplifications I 
am wanting to make here is to say that the driver will always be the 
JTA Synchronization.  So I am trying to determine how "actual" these 
cases where the "JTA Synchronization cannot be registered" are.

The only one that I am aware of IIRC is that JTA Synchronization cannot 
be registered on transactions that are marked for rollback-only.  I 
cannot remember though if that was a specific provider (JBossTS?) or a 
JTA/JTS spec requirement.

So the proposal I have is that for JTA cases we always register the JTA 
Synchronization and allow that to drive the "before/after completion" 
callbacks (the org.hibernate.Transaction would still potentially manage 
actually calling commit/rollback on the 
TransactionManager/UserTransaction).  In short, does any one see 
problems with this approach?


On Wed 04 Dec 2013 11:27:10 AM CST, Steve Ebersole wrote:
> I found a few spare minutes to work on this a little and move it into
> the next stage with some actual interfaces, impls and usages to help
> illustrate some of the proposed concepts.
>
> https://github.com/sebersole/JdbcSession
>
> The README.md is very up-to-date and detailed.  Would be good to get
> input from others.
>
>
> P.S. I probably dislike the *Inflow naming more than you do :)


More information about the hibernate-dev mailing list