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

[Sanne Grinovero]

Hi Jonathan!

So I have multiple options, but fundamentally I have an ORM
SynchronizationRegistry today. We could either follow the example of
the javax.transaction API in evolving the ORM SPI, or apparently I
could explore making our Synchronization stateless and store the state
in this other map instead, or maybe I try refactor it all to stick to
the standard APIs - however I wonder if it will still work for a JDBC
transaction.

Either way I'll take the fact that the standard API exposes such a
functionality as a sign that this could be sensible to expose.

Thanks,
Sanne

On 25 October 2017 at 15:37, Jonathan Halliday
<jonathan.halliday at redhat.com> wrote:
>
> The javax.transaction version of that interface already functions as a
> per-transaction hashmap, with put/get operations available. If you can use
> it directly, then just pick a suitable lookup key - FQCN or even the sync
> impl .class itself, since the key is Object type. If not then at least
> retain the method signatures and just delegate them down through the spi.
>
> https://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchronizationRegistry.html
>
> Jonathan.
>
>
> On 25/10/17 14:32, Sanne Grinovero wrote:
>>
>> Hi Steve,
>>
>> do you think it would be sensible for me to explore introducing some
>> kind of synchronization lookup method on
>> org.hibernate.resource.transaction.spi.SynchronizationRegistry ?
>>
>> Today it only exposes a `registerSynchronization` method, which we use
>> extensively, but then we also have quite some complexity in the Search
>> code caused by the fact that we can't look the synchronizations up in
>> a later phase.
>> Essentially our Synchronization is stateful and we need to update it
>> later.
>>
>> I'd love to propose a change for ORM6 so allow registering such things
>> under some kind of id (a string?) so that one can look them back.
>>
>> current SPI:
>>
>>      public void registerSynchronization(Synchronization synchronization)
>>
>> temptative proposal (didn't try it yet..):
>>
>>     public void registerSynchronization(String id, Synchronization
>> synchronization);
>>
>>     public void Synchronization getSynchronization(String id);
>>
>>
>> does it sound reasonable in principle?
>>
>> This would imply other users should make up an id unique for their use
>> case. Alternatively I could live with a Class used as an id, or we
>> could have the new methods in addition to the existing method for
>> people not interested in looking things up.
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander