Re: [hibernate-dev] JdbcSession proposal

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 >