As Gail and I discussed the actual API to use in this JdbcSession redesign we both liked the idea of sending Operations in to the JdbcSession rather than JdbcSession exposing a very granular, JDBC-like API. This got me to thinking that JdbcSession really could be a generic representation of a connection+transaction context for *any* back end, whether that back-end was JDBC or not.
I discussed this idea a bit with Sanne on IRC. He was on board in the general sense. So this morning I spent some time re-working the code to express this concept. I just pushed this out to my repo. The main contract now is org.hibernate.resource.store.DataStoreSession. The JDBC realization of this contract is defined by org.hibernate.resource.store.jdbc.JdbcSession (which extends the DataStoreSession). The nice thing is that this all ties in seamlessly with the TransactionCoordinator. There is a notion of "resource local transactions" and "jta transactions". "resource local transactions" ultimately come from the DataStoreSession which allows integrating back-end specific notions of transactions by implementing a org.hibernate.resource.transaction.ResourceLocalTransaction for that back end (org.hibernate.resource.store.jdbc.spi.PhysicalJdbcTransaction for example for JDBC). Anyway, it was a nice exercise even if y'all decide to not use this in OGM. It forced me to think about the separation between the 2 main packages (org.hibernate.resource.transaction versus org.hibernate.resource.store) and to remove the cyclic deps. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
