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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team