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
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
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,
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. The integration point between the "local transaction"
(org.hibernate.Transaction) and the TransactionCoordinator is the
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.
 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
 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!).
> ----- 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(a)lists.jboss.org>, "Tom Jenkinson"
>> <tom.jenkinson(a)redhat.com>, "Scott Marlow"
>> 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>
>> 95 times out of 100 inside Hibernate code we really can't take
>> of the parameterized type. So its less important in my mind. Like I
>> 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
>>> getStatementExecutor().execute(), and
>>> getResultSetProcessor().extractResults(), as opposed to
>>> PreparedStatementQueryOperation.prepare(), execute(),
>>> I think there should also be a
>>> PreparedStatementQueryOperation.getStatementBinder() returning a
>>> StatementBinder, since it's really a step that is separate from
>> 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
>> 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.