[hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?
Radim Vansa
rvansa at redhat.com
Wed Oct 25 10:38:20 EDT 2017
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
More information about the hibernate-dev
mailing list