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

[Sanne Grinovero]

On 25 October 2017 at 17:13, Jonathan Halliday
<jonathan.halliday at redhat.com> wrote:
>
> 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?

I agree, that's what I'd want to avoid - at least in the Hibernate Search case.

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

That would work for me, and I wouldn't need polymorphism. Exact class
will do just fine.

So this approach might allow to keep the registration API as-is, but
if we allow to register
multiple instances of the same class the retrieval would return a
random instance.

That's not a problem for my use case and could be addressed with javadoc,
probably a nice compromise.
Incidentally maps keyed by Class are very efficient so that's nice too.

Would it suffice for you too Radim? Since noone else ever asked for
such a feature I think the two of us represent the users population :)

Thanks,
Sanne


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