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

[Jonathan Halliday]

sure, though I was thinking in terms of storing the stateful sync 
directly into the registry, not separating out the state first. Your api 
proposal made that storage a side effect of the registration call, but 
with the javax.transaction api it's an additional call, roughly

tsr.registerSync(statefulThing);
tsr.put(org.hibernate.specialkey, statefulThing);

less elegant, but more flexible in that you can stick things other than 
Synchronizations in there too if you ever need to.

Direct use in a JDBC transaction would need a dummy 
javax.transaction.TransactionSynchronizationRegistry API impl I guess, 
which does seem rather silly if you already got an spi to avoid that, 
but OTOH would not require interface changes.

Ultimately you need a tx context to tie it back to though, since the 
underlying map is per-tx. IIRC in the narayana impl the TSR actually 
delegates to the tx object, which is where the map storage resides. 
Adding the TSR to the JTA spec api was kind of a kludge to avoid 
interfaces changes in the days before defender methods (or whatever they 
would up being called). Most of the TSR methods logically belong to 
Transaction or TransactionManager. If you're keeping map put/get 
semantics decoupled from registerSync semantics, then there is no 
requirement for them to belong on the SynchronizationRegistry rather 
than some other api.

Jonathan.

On 25/10/17 16:02, Sanne Grinovero wrote:
> 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
> 

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