Re: [hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?
On 25 October 2017 at 16:05, Steve Ebersole <steve(a)hibernate.org> wrote:
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?
Yes that would work for me, but thinking about the implementation it
implies you'd need to hold on to both a Set and a Map, and then we'd
be exposed to silly usage like people adding the same synchronization
twice in two different ways?
I'd rather expose a single consistent way: having to make up an id
doesn't seem too inconvenient considering it's an SPI.
Thanks,
Sanne
On Wed, Oct 25, 2017 at 9:37 AM Jonathan Halliday
<jonathan.halliday(a)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/TransactionSynchro...
>
> 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(a)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