[hibernate-dev] JdbcSession proposal

[Gail Badner]

I've been trying to sort out the relationships between JdbcSession, Transaction, TransactionCoordinatorJdbcImpl, PhysicalJdbcTransaction, TransactionCoordinatorJtaImpl, and PhysicalJtaTransaction.

I've only looked at the ReadMe so far. Have you started fleshing that out in the code? I've kind of guessed what you mean in the ReadMe and created https://gist.github.com/gbadner/7837050 . Feel free to ignore this gist if you've already started fleshing this out.

I'm not sure how the synchronizations all work for each case, but I imagine it will really help clean up the logic splitting up the cases (which is great!). 

Regards,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Tom Jenkinson"
> <tom.jenkinson at redhat.com>, "Scott Marlow" <smarlow at redhat.com>
> Sent: Friday, December 6, 2013 7:09:16 PM
> Subject: Re: [hibernate-dev] JdbcSession proposal
> 
> On Fri 06 Dec 2013 05:10:10 PM CST, Gail Badner wrote:
> 
> >
> > It would be nice to make the return value generic:
> >
> > public T accept(PreparedStatementQueryOperation operation, Class<T>
> > resultClass);
> 
> 
> 95 times out of 100 inside Hibernate code we really can't take advantage
> of the parameterized type. So its less important in my mind. Like I said
> earlier, the intent here is not to build a general purpose JDBC
> abstraction library.
> 
> But if you look at Operation you can see it is parameterized
> (Operation<T>) and that accept() leverages that:
> 
> public <T> T accept(Operation<T> operation);
> 
> 
> >
> > 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.
> 
> 
> Yep, I contemplated the same.
> 
> >
> > 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.
> 
> Its the ResourceRegistry which in the actual code.  It does not segment
> resources by the operation they come from atm.  The only thing it x-refs
> is Statement->ResultSets.  I am not sure it is worth the overhead to do
> this segmenting either.
> 
> But you are correct, if we did segment these registered resources by
> operation we would need a level of releasing them by operation too.
>