Yes, but that is only available in JTA environments. Ours is available no
matter what kind of transaction environment we are executing in.
Sanne, how about instead a separate registration method accepting a
"registration key"? E.g.:
public interface SynchronizationRegistry extends Serializable {
// ~~~~~~~~~~~~~~~
// current api
void registerSynchronization(Synchronization synchronization);
// ~~~~~~~~~~~~~~~
// additional api
void registerSynchronization(Object key, Synchronization
synchronization);
Synchronization findSynchronization(Object key);
}
or:
public interface KeyableSynchronization extends Synchronization {
Object getKey();
}
which can be used during #registerSynchronization(Synchronization)
processing to add to a Map as well?
On Wed, Oct 25, 2017 at 9:37 AM Jonathan Halliday <
jonathan.halli...@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@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
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
