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

[Radim Vansa]

On 10/26/2017 01:23 AM, Sanne Grinovero wrote:
> 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 :)

My case was already solved by the CacheTransactionContext, and it seems 
more convenient than doing any lookups. But for general use I find 
by-class lookup more appealing than registering with a custom key. The 
registrar can always use some private class; it's not like unrelated 
components would do lookup of others' synchronizations.

Radim

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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team