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 <smar...@redhat.com> 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" <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
