I tend to agree... On Dec 7, 2013 10:23 AM, "Scott Marlow" <smar...@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" <st...@hibernate.org> >>>>> To: "hibernate-dev" <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@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 >>> >>> >> _______________________________________________ >> 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
