[hibernate-dev] JdbcSession -> DataStoreSession

[Steve Ebersole]

The Operations are store specific.  So there would be a specific 
Operation for performing a JDBC query and either extracting the results 
(normal use) or accessing the ResultSet (ScrollableResults use).   
There would be some other Operation impl(s) for doing the same against 
no-sql stores.  Operation is really meant to be model an end-to-end 
interaction with the backing store.

The thing that "clicked" for me was realizing that even though each 
back-end would need varying Operation impls almost all of these usages 
come from persisters and loaders which OGM already provides 
alternatives for.  We'd just replace them (persisters/loaders and 
DataStoreSession types) in tandem.

Keep in mind that the idea here is simply to centralize the binding of 
connection+transaction in various transaction scenarios and encapsulate 
handling of "flow" between them.



On Mon 16 Dec 2013 01:38:22 AM CST, Emmanuel Bernard wrote:
> When I reviewed your work earlier last week, I had the feeling that we
> would need to replace JdbcSession with something totally different. OGM
> Loader / Persisters would then use that different contract.
>
> The idea of a generic DataStoreSession is attractive.
>
> But something I am not clear on is how the generic parameter of
> Operation will be used. How can a Loader or Persister invoking
> DataStoreSession.accept() retrieves the results? Will it be ResultSet or
> some agnostic container too?
>
> Emmanuel
>
> On Sat 2013-12-14 11:53, Steve Ebersole wrote:
>> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev