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 :)

Hi Steve, Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see: Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only. That would make it a JTA spec requirement. More feedback coming... ----- Original Message ----- > From: "Steve Ebersole" <steve(a)hibernate.org&gt; > To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; > Sent: Friday, December 6, 2013 10:07:22 AM > Subject: Re: [hibernate-dev] JdbcSession proposal > > 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 :) > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

I think this is an excellent question, my preference is to fail-fast in some fashion. JTA 1.1 spec description of Transaction.setRollbackOnly(): " public void setRollbackOnly() throws IllegalStateException, SystemException Modify the transaction associated with the target object such that the only possible outcome of the transaction is to roll back the transaction. " From an EJB point of view, the EJB container will eventually notice that the transaction is marked for rollback only when the EJB bean invocation completes but its not clear (to me) what this means at the JPA level. Might be worth asking the JBossTS team, this question. On 12/06/2013 03:38 PM, Steve Ebersole wrote: > The bigger question is whether we care. Is there really a benefit to > continuing work when a transaction is marked for rollback only? > > > On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: >> Hi Steve, >> >> Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see: >> >> Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only. >> >> That would make it a JTA spec requirement. >> >> More feedback coming... >> >> ----- Original Message ----- >>> From: "Steve Ebersole" <steve(a)hibernate.org&gt; >>> To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; >>> Sent: Friday, December 6, 2013 10:07:22 AM >>> Subject: Re: [hibernate-dev] JdbcSession proposal >>> >>> 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 :) >>> _______________________________________________ >>> 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Sanne Grinovero" <sanne(a)hibernate.org&gt; Cc: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt;, "Gail Badner" <gbadner(a)redhat.com&gt;, "Tom Jenkinson" <tom.jenkinson(a)redhat.com&gt;, "Scott Marlow" <smarlow(a)redhat.com&gt; Sent: Friday, December 6, 2013 2:51:07 PM Subject: Re: [hibernate-dev] JdbcSession proposal Realize that ultimately this is inended for use inside Hibernate. Thats my only goal here. I don't care to write/maintain a general purpose JDBC abstraction library. So I only really care in this context. Does it make sense to continue to allow access to resources if the trabsaction is marked for rollback thoeretically. Whether the TM might optimize access is not relevant to me. Just in principal does it make sense. On Dec 6, 2013 4:43 PM, "Sanne Grinovero" <sanne(a)hibernate.org&gt; wrote: > I'm wondering if someone might want to define such a > PreparedStatementQueryOperation just for reading data. > > In such case, could there be any benefit in setting #setRollbackOnly() ? > I'm not just thinking of being paranoid to "protect" the data from > side-effects but also it could imply that the TransactionManager could > apply some optimisations? > > Sanne > > > On 6 December 2013 21:45, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > I think this is an excellent question, my preference is to fail-fast in > > some fashion. > > > > JTA 1.1 spec description of Transaction.setRollbackOnly(): > > > > " > > public void setRollbackOnly() throws IllegalStateException, > SystemException > > > > Modify the transaction associated with the target object such that the > > only possible outcome of the transaction is to roll back the transaction. > > " > > > > From an EJB point of view, the EJB container will eventually notice > > that the transaction is marked for rollback only when the EJB bean > > invocation completes but its not clear (to me) what this means at the > > JPA level. > > > > Might be worth asking the JBossTS team, this question. > > > > On 12/06/2013 03:38 PM, Steve Ebersole wrote: > >> The bigger question is whether we care. Is there really a benefit to > >> continuing work when a transaction is marked for rollback only? > >> > >> > >> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: > >>> Hi Steve, > >>> > >>> Looking at the Javadoc for > javax.transaction.Transaction.registerSynchronization(Synchronization > sync), I see: > >>> > >>> Throws: RollbackException - Thrown to indicate that the transaction > has been marked for rollback only. > >>> > >>> That would make it a JTA spec requirement. > >>> > >>> More feedback coming... > >>> > >>> ----- Original Message ----- > >>>> From: "Steve Ebersole" <steve(a)hibernate.org&gt; > >>>> To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; > >>>> Sent: Friday, December 6, 2013 10:07:22 AM > >>>> Subject: Re: [hibernate-dev] JdbcSession proposal > >>>> > >>>> 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 :) > >>>> _______________________________________________ > >>>> 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 > >> > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: "Gail Badner" <gbadner(a)redhat.com&gt; Cc: "Sanne Grinovero" <sanne(a)hibernate.org&gt;, "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt;, "Tom Jenkinson" <tom.jenkinson(a)redhat.com&gt;, "Scott Marlow" <smarlow(a)redhat.com&gt; Sent: Friday, December 6, 2013 7:09:16 PM Subject: Re: [hibernate-dev] JdbcSession proposal On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote: > > It would be nice to make the return value generic: > > public T accept(PreparedStatementQueryOperation operation, Class<T> > resultClass); 95 times out of 100 inside Hibernate code we really can't take advantage of the parameterized type. So its less important in my mind. Like I said earlier, the intent here is not to build a general purpose JDBC abstraction library. But if you look at Operation you can see it is parameterized (Operation<T>) and that accept() leverages that: public <T> T accept(Operation<T> operation); > > I can see the merit of breaking out > PreparedStatementQueryOperation.getStatementPreparer(), > getStatementExecutor().execute(), and > getResultSetProcessor().extractResults(), as opposed to > PreparedStatementQueryOperation.prepare(), execute(), extractResults(). > > I think there should also be a > PreparedStatementQueryOperation.getStatementBinder() returning a > StatementBinder, since it's really a step that is separate from preparing. Yep, I contemplated the same. > > In the case where operation.holdOpenResources() == true, which object > would hold the open resources? If it's JdbcSession that manages them, > there would also need to be JdbcSession.closeResources( operation ); > otherwise, something like > PreparedStatementQueryOperation.closeResources() would be needed. Its the ResourceRegistry which in the actual code. It does not segment resources by the operation they come from atm. The only thing it x-refs is Statement->ResultSets. I am not sure it is worth the overhead to do this segmenting either. But you are correct, if we did segment these registered resources by operation we would need a level of releasing them by operation too.

JdbcSession is a centralization of JDBC/transaction handliong (managing the flow of events between the 2). I picked the name as I said because it models the concept on the database side of a session (which is a "connection"+transaction). TransactionCoordinator is its exposed conceptualization of its transactionality. There are (currently just 2) concrete impls (TransactionCoordinatorJdbcImpl and TransactionCoordinatorJtaImpl) for the different usage environments. The other major components of the JdbcSession are the "logical connection" and the "resource registry". In regards to the inter-play between components for transactions, it all centers on the TransactionCoordinator. Think of this guy as the thing that manages all aspects of transactionality as far as Hibernate is concerned. I personally like to think of these as "flows". There are 2 flows when we talk about transactions. I personally call them inflow and outflow: 1) Outflow is the actual management of the "physical transaction". Outflow is when we tell the jdbc connection to start or complete a transaction or when we tell the jta system to start or complete a transaction. 2) Inflow is the process of "transaction events" causing Hibernate to have to "do something". For example, when a transaction is about to complete we might need to initiate a flush, or release jdbc resources, etc. TransactionCoordinator coordinates all these behavoirs. Like I said there are 2 distinct flavors of this now because I think it simplifies the code to do that (polymorphism), rather than to have a single piece of code attempt to handle all cases via if/else blocks. TransactionCoordinatorJdbcImpl is actually already fully hooked up. It works exactly like discussed in the README. But this one was easier. Here inflow and outflow are really the same, and they are demarcated and initiated via the "local transaction", which is the client view of "transaction management". Ultimately "local transaction" maps back to org.hibernate.Transaction, but that integration wont get done until after we integrate this all back upstream[1]. The integration point between the "local transaction" (org.hibernate.Transaction) and the TransactionCoordinator is the org.hibernate.resource.transaction.PhysicalTransactionInflow[2]. Its through this link that the user's transaction requests feed back into the TransactionCoordinator and get handled there appropriately. On the jdbc-transaction side this ultimately needs to get routed to the PhysicalJdbcTransaction to handle "outflow" and to the TransactionCoordinator to handle "inflow". The mechanism would be exactly the same for JTA as well insofar as the general Transaction -> PhysicalTransactionInflow -> TransactionCoordinator flow. I simply paused wiring up the JTA side until the Synchronization thing got decided. [1] BTW, I should point out that this all completely removes the need for TransactionFactory as it is today. Upstream TransactionFactory is a factory for different concrete "local transaction" implementations. Given the proposed changes we would have just one "local transaction" implementation, since all the variation is handled behind the TransactionCoordinator. [2] As I said up front, this is badly named and I am already changing this locally to PhysicalTransactionDelegate On Fri 06 Dec 2013 09:51:38 PM CST, Gail Badner wrote: > I've been trying to sort out the relationships between JdbcSession, > Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction, > TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction. > > I've only looked at the ReadMe so far. Have you started fleshing that > out in the code? I've kind of guessed what you mean in the ReadMe and > created https://gist.github.com/gbadner/7837050 . Feel free to ignore > this gist if you've already started fleshing this out. > > I'm not sure how the synchronizations all work for each case, but I > imagine it will really help clean up the logic splitting up the cases > (which is great!). > > Regards, > Gail > > ----- Original Message ----- >> From: "Steve Ebersole" <steve(a)hibernate.org&gt; >> To: "Gail Badner" <gbadner(a)redhat.com&gt; >> Cc: "Sanne Grinovero" <sanne(a)hibernate.org&gt;, "hibernate-dev" >> <hibernate-dev(a)lists.jboss.org&gt;, "Tom Jenkinson" >> <tom.jenkinson(a)redhat.com&gt;, "Scott Marlow" <smarlow(a)redhat.com&gt; >> Sent: Friday, December 6, 2013 7:09:16 PM >> Subject: Re: [hibernate-dev] JdbcSession proposal >> >> On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote: >> >>> >>> It would be nice to make the return value generic: >>> >>> public T accept(PreparedStatementQueryOperation operation, Class<T> >>> resultClass); >> >> >> 95 times out of 100 inside Hibernate code we really can't take >> advantage >> of the parameterized type. So its less important in my mind. Like I >> said >> earlier, the intent here is not to build a general purpose JDBC >> abstraction library. >> >> But if you look at Operation you can see it is parameterized >> (Operation<T>) and that accept() leverages that: >> >> public <T> T accept(Operation<T> operation); >> >> >>> >>> I can see the merit of breaking out >>> PreparedStatementQueryOperation.getStatementPreparer(), >>> getStatementExecutor().execute(), and >>> getResultSetProcessor().extractResults(), as opposed to >>> PreparedStatementQueryOperation.prepare(), execute(), >>> extractResults(). >>> >>> I think there should also be a >>> PreparedStatementQueryOperation.getStatementBinder() returning a >>> StatementBinder, since it's really a step that is separate from >>> preparing. >> >> >> Yep, I contemplated the same. >> >>> >>> In the case where operation.holdOpenResources() == true, which object >>> would hold the open resources? If it's JdbcSession that manages them, >>> there would also need to be JdbcSession.closeResources( operation ); >>> otherwise, something like >>> PreparedStatementQueryOperation.closeResources() would be needed. >> >> Its the ResourceRegistry which in the actual code. It does not segment >> resources by the operation they come from atm. The only thing it >> x-refs >> is Statement->ResultSets. I am not sure it is worth the overhead to do >> this segmenting either. >> >> But you are correct, if we did segment these registered resources by >> operation we would need a level of releasing them by operation too. >>

On 12/06/2013 04:45 PM, Scott Marlow wrote: > I think this is an excellent question, my preference is to fail-fast in > some fashion. > > JTA 1.1 spec description of Transaction.setRollbackOnly(): > > " > public void setRollbackOnly() throws IllegalStateException, > SystemException > > Modify the transaction associated with the target object such that the > only possible outcome of the transaction is to roll back the transaction. > " > > From an EJB point of view, the EJB container will eventually notice > that the transaction is marked for rollback only when the EJB bean > invocation completes but its not clear (to me) what this means at the > JPA level. > > Might be worth asking the JBossTS team, this question. > I believe that a future EE or JPA expert group will discuss whether applications can expect a transaction to fail-fast in the JPA persistence provider. The discussion about this came up as part of a TCK issue (CTS-182 related whatever that is ;) I'm in favor of fail-fast as soon as possible, so that the application doesn't spend (potentially), hours before attempting to commit the JTA transaction, only to then realize that it is marked rollback only. This doesn't seem that much different than detecting that the active JTA transaction has timed out. > On 12/06/2013 03:38 PM, Steve Ebersole wrote: > >> The bigger question is whether we care. Is there really a benefit to >> continuing work when a transaction is marked for rollback only? >> >> >> On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: >> >>> Hi Steve, >>> >>> Looking at the Javadoc for javax.transaction.Transaction. >>> registerSynchronization(Synchronization sync), I see: >>> >>> Throws: RollbackException - Thrown to indicate that the transaction has >>> been marked for rollback only. >>> >>> That would make it a JTA spec requirement. >>> >>> More feedback coming... >>> >>> ----- Original Message ----- >>> >>>> From: "Steve Ebersole" <steve(a)hibernate.org&gt; >>>> To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org&gt; >>>> Sent: Friday, December 6, 2013 10:07:22 AM >>>> Subject: Re: [hibernate-dev] JdbcSession proposal >>>> >>>> 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 :) >>>>> >>>> _______________________________________________ >>>> 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 >> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

I tend to agree... On Dec 7, 2013 10:23 AM, "Scott Marlow" <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: On 12/06/2013 04:45 PM, Scott Marlow wrote: I think this is an excellent question, my preference is to fail-fast in some fashion. JTA 1.1 spec description of Transaction.setRollbackOnly(): " public void setRollbackOnly() throws IllegalStateException, SystemException Modify the transaction associated with the target object such that the only possible outcome of the transaction is to roll back the transaction. " From an EJB point of view, the EJB container will eventually notice that the transaction is marked for rollback only when the EJB bean invocation completes but its not clear (to me) what this means at the JPA level. Might be worth asking the JBossTS team, this question. I believe that a future EE or JPA expert group will discuss whether applications can expect a transaction to fail-fast in the JPA persistence provider. The discussion about this came up as part of a TCK issue (CTS-182 related whatever that is ;) I'm in favor of fail-fast as soon as possible, so that the application doesn't spend (potentially), hours before attempting to commit the JTA transaction, only to then realize that it is marked rollback only. This doesn't seem that much different than detecting that the active JTA transaction has timed out. On 12/06/2013 03:38 PM, Steve Ebersole wrote: The bigger question is whether we care. Is there really a benefit to continuing work when a transaction is marked for rollback only? On Fri 06 Dec 2013 02:36:38 PM CST, Gail Badner wrote: Hi Steve, Looking at the Javadoc for javax.transaction.Transaction.registerSynchronization(Synchronization sync), I see: Throws: RollbackException - Thrown to indicate that the transaction has been marked for rollback only. That would make it a JTA spec requirement. More feedback coming... ----- Original Message ----- From: "Steve Ebersole" <steve(a)hibernate.org <mailto:steve@hibernate.org>> To: "hibernate-dev" <hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>> Sent: Friday, December 6, 2013 10:07:22 AM Subject: Re: [hibernate-dev] JdbcSession proposal 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 :) _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

> * Relying on the JTA Synchronization makes sense conceptually, but have we received any feedback from JBossTS? > * Regarding the above, +1 for (conceptually) not caring about Synchronization failing for rollback-only and failing fast. But, just want to make sure we're not overlooking something. Yep. I have discussed with Tom a few times. Scott and I are doing one last round of discussion with him just to re-re-re-confirm.

Steve, This is the test case that I was talking about on IRC. It simulates what happens when several remote EJB calls occur using the same JTA transaction. This case is probably common enough that we should solve it. The workaround is to set hibernate.jta.track_by_thread=false. On 06/24/2014 10:23 PM, Scott Marlow wrote: > I pushed a test case that simulates what can happen with remote EJB > invocations that share the same JTA transaction & EntityManager. The > "Transaction was rolled back in a different thread!" error [2] is thrown > but shouldn't be, since the active application thread has changed to a > different thread (which can happen). The workaround is to set > "hibernate.jta.track_by_thread" to false. > > I think that we need to save the thread id at the start of every > application call into the EntityManager.

> > Scott > > [1] https://github.com/scottmarlow/hibernate-orm/tree/sametx_multithreads > > [2] https://gist.github.com/scottmarlow/63c4ab686368853d759b > _______________________________________________ > 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

Sanne, One question that I didn't ask before, when the Hibernate Synchronization.afterCompletion(int) is called (with rolledback TX status), how does Hibernate know if the transaction was rolled back from the transaction reaper thread? I tried checking the thread name in WildFly integration code but that is wrong, as the thread name may be a transaction manager communications thread that is invoked on behalf of a remote (JVM) reaper thread. Currently, are checking thread ids which does not work for the distributed case involving multiple jvms. The current approach also does not work for remote invocations that use the same JTA transaction (as the below test case simulates). Scott On 08/07/2014 11:02 AM, Sanne Grinovero wrote: > Steve, > we had a conversation about this on IRC, I think we came to a > ​ hopefully​ > nice > ​ > ​solution > . > > [15:18] <sannegrinovero> andrigtmiller: I still think you're locking out > the TXM, not making it possible to legitimately timeout queries.. > [15:19] <sannegrinovero> (but I don't have the full picture.. not really > my area) > [15:19] <smarlow> that is a transaction manager concern but they already > handled calling other synchronization call backs. currently, Arjuna > holds a lock on the collection of synchronizations at that time, so > there should be no conflict > [15:20] <smarlow> I asked about your concern yesterday to make sure we > wouldn't deadlock > [15:20] <sannegrinovero> I wasn't actually thinking about deadlock, I > just don't see what you're aiming at with the single lock on the Session > [15:22] <smarlow> to avoid calling Hibernate session.clear from a > background thread while the application thread is also doing a Hibernate > session invocation. which can lead to random exceptions > [15:22] <smarlow> I'm aiming at solving the concurrency concern ^ > [15:22] <sannegrinovero> But I guess you'd need to talk with sebersole, > this lock thing you're proposing comes out of the blue for me :) > [15:22] <sannegrinovero> yes I get that > [15:23] <sannegrinovero> but you should allow the session.clear() to > proceed, not lock it out > [15:23] <smarlow> sure, I'm just trying to talk to who ever listens and > have feedback. Before I get anyway near code changes, Sebersole needs > to be on board (he isn't yet) > [15:24] <sannegrinovero> I'm neither :) willing to discuss for sake of > interest, but can't replace sebersole on this I think :) > [15:24] <smarlow> I posted on as7 dev mailing list a few years ago and > the only feedback that I got was that only Hibernate was not handling > concurrency but there could be others > [15:25] <sannegrinovero> what is the effect you expect to have users see > when the background thread kills the current session? > [15:25] <smarlow> I cross posted as well > [15:25] <smarlow> users shouldn't get NPE errors or unexpected exceptions > [15:26] <sannegrinovero> sure, but what kind of effect would you propose? > [15:26] <sannegrinovero> I guess a different exception with a better > error message? > [15:26] <smarlow> my goal is ensuring that only one thread is invoking > the Hibernate session at a time > [15:27] <sannegrinovero> No that's not true, as you're saying that you > want to allow the TXM to rollback the transaction > [15:27] <smarlow> well, want is a strong word :) > [15:28] <smarlow> IBM/Oracle/JBoss all do that > [15:28] <sannegrinovero> and that's an implementation detail what you > just explained :) > [15:28] <sannegrinovero> what I'm asking is what you expect the user to > experience when this needs to happen > [15:29] <smarlow> when the transaction is rolled back, depending on > where the application code is in the Hibernate session invocation, a > JDBC error might occur or something related to that. The goal is to > avoid mutating the Hibernate session from two different threads concurrently > [15:30] <sannegrinovero> you're not answering my question, that's an > implementation detail :) > [15:30] <smarlow> if we can avoid violating concurrency of the hibernate > session, I think we will be more robust. > [15:31] <sannegrinovero> The goal of the TXM timeout, is to kill stuff > which is taking too long.. not allowing it to finish in a safe lock. > andrigtmiller am I understanding the basics correctly? > [15:31] <smarlow> currently, what the user will experience is poor. The > scope of turning that into a more pleasant experience is a good question > but involves many moving and separate parts > [15:32] <sannegrinovero> so you actually _need_ to allow concurrent > access, to kill and rollback the operations which are being done > [15:32] <smarlow> the goal of TXM timeout handling in JBoss/Oracle/IBM > is to also handle deadlocks that might not otherwise be recovered from > [15:32] <smarlow> the concurrent access happens at the resource level > [15:33] <smarlow> from the background, with components that handle > concurrency. Hibernate doesn't > [15:33] <sannegrinovero> that's just one part of the things > [15:33] <sannegrinovero> and we can definitely have Hibernate handle > some concurrent events > [15:33] <smarlow> Hibernate sessions are not supposed to handle > concurrency, so its a design flaw > [15:33] <sannegrinovero> the TXM shouldn't invoke clear() (which is > public API) but invoke a specific method which could provide the needed > semantics > [15:33] <smarlow> its not some events, its many events > [15:34] <sannegrinovero> why do you say it's a design flaw? it's not, > for the "normal" public API usage > [15:34] <smarlow> the TXM, calls the Hibernate > Synchronization.afterCompletion(int) and Hibernate detaches entities > [15:34] <smarlow> and Hibernate does other cleaning up as well > [15:35] <smarlow> its a design flaw as its not handled in our system > [15:35] <sannegrinovero> I don't feel I'm making progress in the > conversation if you keep repeating the implementation details, we can > fix that as we please > [15:35] <sannegrinovero> but you have to explain the expected user > experience > [15:36] <smarlow> you mean if we didn't have any constraints of any of > the existing specs that we implement? > [15:36] <sannegrinovero> yes, just explain what you think it should do > please, that would help me understand, and I think I can propose you > something more concrete > [15:37] <smarlow> if we ignore XA, JTA + JPA, I can answer the question > better and will attempt that > [15:37] <sannegrinovero> the problem is the user sees an NPE right? > [15:38] <smarlow> could be an NPE or any unexpected exception that comes > from using a thread-unsafe component from multiple threads > [15:38] <sannegrinovero> so the basic question is what do you think the > user should "see".. I guess another exception, say > HibernateRolledBackException("The Transaction Manager decided we run out > of time") > [15:38] <sannegrinovero> sure. would you like the above proposal ^ > [15:39] <sannegrinovero> Because implementing that is easy :) > [15:41] <sannegrinovero> ? If you're busy I'm happy to talk later, I am > 3h late with my lunch > [15:41] <smarlow> in a perfect world, 1) the user registers an > application event listener that tells that the transaction timed out. > 2) whether the application thread catches a signal that the > transaction is about to be rolled back. 3) The application thread then > catches a signal that the transaction was rolled back > [15:41] <sannegrinovero> that doesn't explain what you expect the client > code to experience. > [15:41] <smarlow> 4) the application thread then catches a signal that > Synchronization call backs are going to happen to clean up after the > roll back > [15:42] <sannegrinovero> say the user was incoking a "Query.list()" .. > what do we return? > [15:42] <smarlow> what could they expect? They could be in the middle > of code that doesn't use the Hibernate session or could be in code that does > [15:43] <sannegrinovero> Exactly my point, so we'd return an exception > like I proposed above right? > [15:43] <smarlow> if you say so but no one knows how to do that > [15:43] <smarlow> I mean, I'm not sure what returns that > [15:44] <smarlow> we had tried doing what you suggest but it was too > performance expensive and covered too few cases > [15:44] <smarlow> but sure, throwing an EJB rolledback exception is ideal > [15:45] <sannegrinovero> you can do it in an efficient way, but yes I > agree you'd have to patch several areas of code. > [15:45] <sannegrinovero> I'd do it incrementally though, start with the > Session and Query APIs, see if people like it > [15:45] <smarlow> our previous attempt that failed, added a pre-check at > the front of every Hibernate session call, tail end and middle > [15:46] <smarlow> but that didn't work because it didn't handle remote > transactions or distributed transactions > [15:46] <sannegrinovero> the EntityManager implementation has some kind > of "exception translator" > [15:46] <smarlow> and performance suffered > [15:46] <sannegrinovero> all you need to do is catch exceptions, and > re-throw the better explanation > [15:46] <smarlow> so, we have less of the checking today and still don't > handle remote transactions and distributed transactions > [15:47] <sannegrinovero> the TXM just needs to flag a volatile field in > the Session to inject the error it wants us to tell > [15:47] <sannegrinovero> so on the optimal path you just have a volatile > field read operation, which is a zero cost essentially > [15:47] <sannegrinovero> (optimal path I mean the case in which there > are no errors) > [15:48] <smarlow> then we need to poll for that flag in the > start/middle/end (or so) if every Hibernate method > [15:48] <sannegrinovero> no > [15:48] <smarlow> or maybe in the finally clause of every method > [15:48] <sannegrinovero> you just need to catch exceptions > [15:48] <sannegrinovero> and we happen to already do that, because you > need to translate all Hibernate specific exceptions to JPA specific ones > [15:49] <sannegrinovero> so it's actually a very simple patch with zero > overhead I think > [15:49] <smarlow> at worse, we catch exceptions (including NPE) and > notice the flag and then eat the cause exception? > [15:49] <sannegrinovero> +1 > [15:49] <smarlow> if we show the cause, its confusing > [15:49] <sannegrinovero> you don't need the finally method either though > [15:49] <smarlow> if we eat it, its confusing > [15:49] <sannegrinovero> right, don't show the cause. > [15:49] <smarlow> I hate when exceptions are eaten > [15:50] <sannegrinovero> well.. the TXM should provide you a sensible > error message, like "aborted because of ... ", and we take that as > explanation. > [15:50] <smarlow> but only if that flag is set > [15:50] <sannegrinovero> of course! > [15:50] <smarlow> sounds like a worthwhile idea, thanks > [15:51] <sannegrinovero> np, I'm very happy if it works :) > [15:51] <sannegrinovero> the exception translation is already done > somewhere in the EM project > [15:51] <sannegrinovero> I don't remember the details, but I'm sure > you're more familiar with it > [15:51] <sannegrinovero> just make sure you look that up > [15:52] <sannegrinovero> it catches all exceptions from Hibernate to > wrap them in something else, to satisfy the spec requirements > > -- Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

We only check whether the thread is different from the "application thread". As I have mentioned to you about a bazillion times now (give or take ;) this is all a best effort. As you well know, we simply do not have all the pertinent information we need to know what the nature of the various threads in play are.

On Thu, Aug 7, 2014 at 10:33 AM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: Sanne, One question that I didn't ask before, when the Hibernate Synchronization.__afterCompletion(int) is called (with rolledback TX status), how does Hibernate know if the transaction was rolled back from the transaction reaper thread? I tried checking the thread name in WildFly integration code but that is wrong, as the thread name may be a transaction manager communications thread that is invoked on behalf of a remote (JVM) reaper thread. Currently, are checking thread ids which does not work for the distributed case involving multiple jvms. The current approach also does not work for remote invocations that use the same JTA transaction (as the below test case simulates). Scott On 08/07/2014 11:02 AM, Sanne Grinovero wrote: Steve, we had a conversation about this on IRC, I think we came to a ​ hopefully​ nice ​ ​solution . [15:18] <sannegrinovero> andrigtmiller: I still think you're locking out the TXM, not making it possible to legitimately timeout queries.. [15:19] <sannegrinovero> (but I don't have the full picture.. not really my area) [15:19] <smarlow> that is a transaction manager concern but they already handled calling other synchronization call backs. currently, Arjuna holds a lock on the collection of synchronizations at that time, so there should be no conflict [15:20] <smarlow> I asked about your concern yesterday to make sure we wouldn't deadlock [15:20] <sannegrinovero> I wasn't actually thinking about deadlock, I just don't see what you're aiming at with the single lock on the Session [15:22] <smarlow> to avoid calling Hibernate session.clear from a background thread while the application thread is also doing a Hibernate session invocation. which can lead to random exceptions [15:22] <smarlow> I'm aiming at solving the concurrency concern ^ [15:22] <sannegrinovero> But I guess you'd need to talk with sebersole, this lock thing you're proposing comes out of the blue for me :) [15:22] <sannegrinovero> yes I get that [15:23] <sannegrinovero> but you should allow the session.clear() to proceed, not lock it out [15:23] <smarlow> sure, I'm just trying to talk to who ever listens and have feedback. Before I get anyway near code changes, Sebersole needs to be on board (he isn't yet) [15:24] <sannegrinovero> I'm neither :) willing to discuss for sake of interest, but can't replace sebersole on this I think :) [15:24] <smarlow> I posted on as7 dev mailing list a few years ago and the only feedback that I got was that only Hibernate was not handling concurrency but there could be others [15:25] <sannegrinovero> what is the effect you expect to have users see when the background thread kills the current session? [15:25] <smarlow> I cross posted as well [15:25] <smarlow> users shouldn't get NPE errors or unexpected exceptions [15:26] <sannegrinovero> sure, but what kind of effect would you propose? [15:26] <sannegrinovero> I guess a different exception with a better error message? [15:26] <smarlow> my goal is ensuring that only one thread is invoking the Hibernate session at a time [15:27] <sannegrinovero> No that's not true, as you're saying that you want to allow the TXM to rollback the transaction [15:27] <smarlow> well, want is a strong word :) [15:28] <smarlow> IBM/Oracle/JBoss all do that [15:28] <sannegrinovero> and that's an implementation detail what you just explained :) [15:28] <sannegrinovero> what I'm asking is what you expect the user to experience when this needs to happen [15:29] <smarlow> when the transaction is rolled back, depending on where the application code is in the Hibernate session invocation, a JDBC error might occur or something related to that. The goal is to avoid mutating the Hibernate session from two different threads concurrently [15:30] <sannegrinovero> you're not answering my question, that's an implementation detail :) [15:30] <smarlow> if we can avoid violating concurrency of the hibernate session, I think we will be more robust. [15:31] <sannegrinovero> The goal of the TXM timeout, is to kill stuff which is taking too long.. not allowing it to finish in a safe lock. andrigtmiller am I understanding the basics correctly? [15:31] <smarlow> currently, what the user will experience is poor. The scope of turning that into a more pleasant experience is a good question but involves many moving and separate parts [15:32] <sannegrinovero> so you actually _need_ to allow concurrent access, to kill and rollback the operations which are being done [15:32] <smarlow> the goal of TXM timeout handling in JBoss/Oracle/IBM is to also handle deadlocks that might not otherwise be recovered from [15:32] <smarlow> the concurrent access happens at the resource level [15:33] <smarlow> from the background, with components that handle concurrency. Hibernate doesn't [15:33] <sannegrinovero> that's just one part of the things [15:33] <sannegrinovero> and we can definitely have Hibernate handle some concurrent events [15:33] <smarlow> Hibernate sessions are not supposed to handle concurrency, so its a design flaw [15:33] <sannegrinovero> the TXM shouldn't invoke clear() (which is public API) but invoke a specific method which could provide the needed semantics [15:33] <smarlow> its not some events, its many events [15:34] <sannegrinovero> why do you say it's a design flaw? it's not, for the "normal" public API usage [15:34] <smarlow> the TXM, calls the Hibernate Synchronization.__afterCompletion(int) and Hibernate detaches entities [15:34] <smarlow> and Hibernate does other cleaning up as well [15:35] <smarlow> its a design flaw as its not handled in our system [15:35] <sannegrinovero> I don't feel I'm making progress in the conversation if you keep repeating the implementation details, we can fix that as we please [15:35] <sannegrinovero> but you have to explain the expected user experience [15:36] <smarlow> you mean if we didn't have any constraints of any of the existing specs that we implement? [15:36] <sannegrinovero> yes, just explain what you think it should do please, that would help me understand, and I think I can propose you something more concrete [15:37] <smarlow> if we ignore XA, JTA + JPA, I can answer the question better and will attempt that [15:37] <sannegrinovero> the problem is the user sees an NPE right? [15:38] <smarlow> could be an NPE or any unexpected exception that comes from using a thread-unsafe component from multiple threads [15:38] <sannegrinovero> so the basic question is what do you think the user should "see".. I guess another exception, say HibernateRolledBackException("__The Transaction Manager decided we run out of time") [15:38] <sannegrinovero> sure. would you like the above proposal ^ [15:39] <sannegrinovero> Because implementing that is easy :) [15:41] <sannegrinovero> ? If you're busy I'm happy to talk later, I am 3h late with my lunch [15:41] <smarlow> in a perfect world, 1) the user registers an application event listener that tells that the transaction timed out. 2) whether the application thread catches a signal that the transaction is about to be rolled back. 3) The application thread then catches a signal that the transaction was rolled back [15:41] <sannegrinovero> that doesn't explain what you expect the client code to experience. [15:41] <smarlow> 4) the application thread then catches a signal that Synchronization call backs are going to happen to clean up after the roll back [15:42] <sannegrinovero> say the user was incoking a "Query.list()" .. what do we return? [15:42] <smarlow> what could they expect? They could be in the middle of code that doesn't use the Hibernate session or could be in code that does [15:43] <sannegrinovero> Exactly my point, so we'd return an exception like I proposed above right? [15:43] <smarlow> if you say so but no one knows how to do that [15:43] <smarlow> I mean, I'm not sure what returns that [15:44] <smarlow> we had tried doing what you suggest but it was too performance expensive and covered too few cases [15:44] <smarlow> but sure, throwing an EJB rolledback exception is ideal [15:45] <sannegrinovero> you can do it in an efficient way, but yes I agree you'd have to patch several areas of code. [15:45] <sannegrinovero> I'd do it incrementally though, start with the Session and Query APIs, see if people like it [15:45] <smarlow> our previous attempt that failed, added a pre-check at the front of every Hibernate session call, tail end and middle [15:46] <smarlow> but that didn't work because it didn't handle remote transactions or distributed transactions [15:46] <sannegrinovero> the EntityManager implementation has some kind of "exception translator" [15:46] <smarlow> and performance suffered [15:46] <sannegrinovero> all you need to do is catch exceptions, and re-throw the better explanation [15:46] <smarlow> so, we have less of the checking today and still don't handle remote transactions and distributed transactions [15:47] <sannegrinovero> the TXM just needs to flag a volatile field in the Session to inject the error it wants us to tell [15:47] <sannegrinovero> so on the optimal path you just have a volatile field read operation, which is a zero cost essentially [15:47] <sannegrinovero> (optimal path I mean the case in which there are no errors) [15:48] <smarlow> then we need to poll for that flag in the start/middle/end (or so) if every Hibernate method [15:48] <sannegrinovero> no [15:48] <smarlow> or maybe in the finally clause of every method [15:48] <sannegrinovero> you just need to catch exceptions [15:48] <sannegrinovero> and we happen to already do that, because you need to translate all Hibernate specific exceptions to JPA specific ones [15:49] <sannegrinovero> so it's actually a very simple patch with zero overhead I think [15:49] <smarlow> at worse, we catch exceptions (including NPE) and notice the flag and then eat the cause exception? [15:49] <sannegrinovero> +1 [15:49] <smarlow> if we show the cause, its confusing [15:49] <sannegrinovero> you don't need the finally method either though [15:49] <smarlow> if we eat it, its confusing [15:49] <sannegrinovero> right, don't show the cause. [15:49] <smarlow> I hate when exceptions are eaten [15:50] <sannegrinovero> well.. the TXM should provide you a sensible error message, like "aborted because of ... ", and we take that as explanation. [15:50] <smarlow> but only if that flag is set [15:50] <sannegrinovero> of course! [15:50] <smarlow> sounds like a worthwhile idea, thanks [15:51] <sannegrinovero> np, I'm very happy if it works :) [15:51] <sannegrinovero> the exception translation is already done somewhere in the EM project [15:51] <sannegrinovero> I don't remember the details, but I'm sure you're more familiar with it [15:51] <sannegrinovero> just make sure you look that up [15:52] <sannegrinovero> it catches all exceptions from Hibernate to wrap them in something else, to satisfy the spec requirements -- Sanne