[hibernate-dev] JdbcSession proposal

Fri Dec 6 18:10:10 EST 2013

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" <steve at hibernate.org>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Gail Badner" <gbadner at redhat.com>, "Tom Jenkinson"
> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at 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" <sanne at 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 <smarlow at 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" <steve at hibernate.org>
> > >>>> To: "hibernate-dev" <hibernate-dev at 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 at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> 