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

[Jonathan Halliday]

so you have some form of implicit cleanup that de-registers 
Synchronizations when the transaction finishes, or do they stay 
registered and re-fire for each tx on the connection?

As to the multiple registration semantics, IIRC the arjuna code allows 
the same Synchronization to be registered multiple times and in such 
case it will be called multiple times too. No reason you need to follow 
that model unless you're delegating to the tx engine though. If you go 
for 'we always generate the key for you', then calling

String id = sr.register(sync)

twice could just give you back the same id. Downside is you need to 
store that id someplace, which misses the point of allowing a fixed 
constant as the key. I'm rather assuming that's the requirement here, 
since if you're needing to keep and pass around a uniq key then you may 
as well just pass around the sync object itself? Anyhow, is a key of any 
form necessary for that use case? Could retrieval just be

sr.getSynchronizationsOfType(thing.class)

to match on class/interface, which should be all that's needed to find 
e.g. the cache/search/whatever synchronization.  Not having a key means 
saves having to define how it behaves. Lookup maybe slower if you're 
going to support polymorphism though, but the number of Synchronizations 
per tx should be small.

Jonathan.

On 25/10/17 16:39, Steve Ebersole wrote:
> 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 <mailto: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>
>      > <mailto: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>
>      >     <mailto: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
> 

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