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
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
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
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.