[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

JdbcSession is a centralization of JDBC/transaction handliong (managing 
the flow of events between the 2).  I picked the name as I said because 
it models the concept on the database side of a session (which is a 
"connection"+transaction).

TransactionCoordinator is its exposed conceptualization of its 
transactionality.  There are (currently just 2) concrete impls 
(TransactionCoordinatorJdbcImpl and TransactionCoordinatorJtaImpl) for 
the different usage environments.

The other major components of the JdbcSession are the "logical 
connection" and the "resource registry".

In regards to the inter-play between components for transactions, it 
all centers on the TransactionCoordinator.  Think of this guy as the 
thing that manages all aspects of transactionality as far as Hibernate 
is concerned.  I personally like to think of these as "flows".  There 
are 2 flows when we talk about transactions.  I personally call them 
inflow and outflow:

1) Outflow is the actual management of the "physical transaction".  
Outflow is when we tell the jdbc connection to start or complete a 
transaction or when we tell the jta system to start or complete a 
transaction.
2) Inflow is the process of "transaction events" causing Hibernate to 
have to "do something".  For example, when a transaction is about to 
complete we might need to initiate a flush, or release jdbc resources, 
etc.

TransactionCoordinator coordinates all these behavoirs.  Like I said 
there are 2 distinct flavors of this now because I think it simplifies 
the code to do that (polymorphism), rather than to have a single piece 
of code attempt to handle all cases via if/else blocks.

TransactionCoordinatorJdbcImpl is actually already fully hooked up.  It 
works exactly like discussed in the README.  But this one was easier.  
Here inflow and outflow are really the same, and they are demarcated 
and initiated via the "local transaction", which is the client view of 
"transaction management".  Ultimately "local transaction" maps back to 
org.hibernate.Transaction, but that integration wont get done until 
after we integrate this all back upstream[1].  The integration point 
between the "local transaction" (org.hibernate.Transaction) and the 
TransactionCoordinator is the 
org.hibernate.resource.transaction.PhysicalTransactionInflow[2].  Its 
through this link that the user's transaction requests feed back into 
the TransactionCoordinator and get handled there appropriately.  On the 
jdbc-transaction side this ultimately needs to get routed to the 
PhysicalJdbcTransaction to handle "outflow" and to the 
TransactionCoordinator to handle "inflow".

The mechanism would be exactly the same for JTA as well insofar as the 
general Transaction -> PhysicalTransactionInflow -> 
TransactionCoordinator flow.  I simply paused wiring up the JTA side 
until the Synchronization thing got decided.


[1] BTW, I should point out that this all completely removes the need 
for TransactionFactory as it is today.  Upstream TransactionFactory is 
a factory for different concrete "local transaction" implementations.  
Given the proposed changes we would have just one "local transaction" 
implementation, since all the variation is handled behind the 
TransactionCoordinator.

[2] As I said up front, this is badly named and I am already changing 
this locally to PhysicalTransactionDelegate





On Fri 06 Dec 2013 09:51:38 PM CST, Gail Badner wrote:
> 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.
>>