[hibernate-dev] JdbcSession proposal

[Steve Ebersole]

It would be better to find different terms than inflow and outflow 
here.  The problem is that in/out depend on perspective and will be 
confusing depending on which part of the code you are in.  I think 
better terms are:

1) transaction management or transaction driving as the process of 
telling the jdbc connection to start or complete a transaction or 
telling the jta system to start or complete a transaction.
2) transaction reaction (?) for the process of reacting to transaction 
events


On Fri 06 Dec 2013 10:26:18 PM CST, Steve Ebersole wrote:
> 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.
>>>