[hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?

[Jonathan Halliday]

right, a lot of JTA works on the 'tx bound to thread' approach and it's 
a right pain in async I/O thread pooled environments like vert.x  That's 
one of the reasons why sticking a get/put api on the Transaction 
instance abstraction instead may make more sense, though I'm guessing 
your SynchronizationRegistry is instance per tx rather than a singleton 
like the JTA one is, so it may not make much difference which object 
carries the functionality for your case?

Jonathan.

On 25/10/17 16:25, Steve Ebersole wrote:
> Also, unless I am mistaken `TransactionSynchronizationRegistry#put` 
> works on the principle that the "current transaction" is associated with 
> the current thread.  I absolutely want to stay away from that as an 
> assumption here.  It simply does not hold true in the JDBC txn case.
> 
> On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
> 
>     Jonathan, we aren't going to be exposing this or using this
>     via TransactionSynchronizationRegistry.  Your comment about a
>     "dummy" in the JDBC txn case is exactly why.  We already have such
>     an abstraction : SynchronizationRegistry
> 
>     On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <steve at hibernate.org
>     <mailto:steve at hibernate.org>> wrote:
> 
>             Yes that would work for me, but thinking about the
>             implementation it
>             implies you'd need to hold on to both a Set and a Map, and
>             then we'd
>             be exposed to silly usage like people adding the same
>             synchronization
>             twice in two different ways?
> 
> 
>         Does it?  Nothing in the SPI requires us to store things in any
>         specific way.  E.g. we can keep just a Map - when we are passed
>         a KeyableSynchronization we'd use that key, when we are passed a
>         non-KeyableSynchronization Synchronization we'd generate one
>         ourselves.
> 
>         And we cant stop people from every conceivable "silly usage". 
>         At some point we are professional developers and should be able
>         to do the non-silly things ;)
> 
>         And as far as your "register the thing twice" worry...
>         rhetorically, what stops them from calling:
> 
>         reg.register( "abc", MySync.INSTANCE )
>         reg.register( "123", MySync.INSTANCE )
> 
>         Nothing.
> 
> 
>             I'd rather expose a single consistent way: having to make up
>             an id
>             doesn't seem too inconvenient considering it's an SPI.
> 
> 
>         Well, again, I don't see how KeyableSynchronization is a
>         "inconsistent" approach.  In fact out of the 2, it is my preferance.
> 

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander