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

[Radim Vansa]

I had the same issue in 2LC and we ended up passing 
CacheTransactionContext to all SPI calls (for ORM6). In case of 
Infinispan impl this will be a stateful object, probably implementing 
the Synchronization iface as well (to reduce object count), and 2LC will 
store all the beforeCompletion/afterCompletion work in there.

Currently we can workaround by registering multiple synchronizations but 
as the RPCs can be done asynchronously doing it in parallel will reduce 
the latency.

The only drawback is that JTA's suspend and resume cannot be honored 
properly but I've been told that the rest of ORM is not working 
perfectly either when you try to run two concurrent transactions using 
single Session.

Radim

On 10/25/2017 03:32 PM, 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


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