WRT Granularity of the JDBC abstraction API... I really like how encapsulating the operation into a PreparedStatementQueryOperation that is executed by JdbcSession.accept( operation ) would clean up existing code. IMO execute( operation ) would be a better name.
It would be nice to make the return value generic: public T accept(PreparedStatementQueryOperation operation, Class<T> resultClass); 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. 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. In the case of a rollback, closeResources() would have to do the right thing (whatever that is). Regards, Gail ----- Original Message ----- > From: "Steve Ebersole" <st...@hibernate.org> > To: "Sanne Grinovero" <sa...@hibernate.org> > Cc: "hibernate-dev" <hibernate-dev@lists.jboss.org>, "Gail Badner" > <gbad...@redhat.com>, "Tom Jenkinson" > <tom.jenkin...@redhat.com>, "Scott Marlow" <smar...@redhat.com> > 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" <sa...@hibernate.org> 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 <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
