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

[Steve Ebersole]

The SynchronizationRegistry is kept per-LogicalConncection which might span
multiple physical transactions.

On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday <
jonathan.halliday at redhat.com> wrote:

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