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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev