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(a)hibernate.org>
To: "Gail Badner" <gbadner(a)redhat.com>
Cc: "Sanne Grinovero" <sanne(a)hibernate.org>, "hibernate-dev"
<hibernate-dev(a)lists.jboss.org>, "Tom Jenkinson"
<tom.jenkinson(a)redhat.com>, "Scott Marlow" <smarlow(a)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.