Re: [hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?
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.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