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" <st...@hibernate.org> >>> To: "Gail Badner" <gbad...@redhat.com> >>> Cc: "Sanne Grinovero" <sa...@hibernate.org>, "hibernate-dev" >>> <hibernate-dev@lists.jboss.org>, "Tom Jenkinson" >>> <tom.jenkin...@redhat.com>, "Scott Marlow" <smar...@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. >>> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
