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
