On 25 October 2017 at 16:05, Steve Ebersole <st...@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.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
