Hi Jonathan! So I have multiple options, but fundamentally I have an ORM SynchronizationRegistry today. We could either follow the example of the javax.transaction API in evolving the ORM SPI, or apparently I could explore making our Synchronization stateless and store the state in this other map instead, or maybe I try refactor it all to stick to the standard APIs - however I wonder if it will still work for a JDBC transaction.
Either way I'll take the fact that the standard API exposes such a functionality as a sign that this could be sensible to expose. Thanks, Sanne On 25 October 2017 at 15:37, 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
