The SynchronizationRegistry is kept per-LogicalConncection which might span multiple physical transactions.
On Wed, Oct 25, 2017 at 10:37 AM Jonathan Halliday < jonathan.halli...@redhat.com> wrote: > > right, a lot of JTA works on the 'tx bound to thread' approach and it's > a right pain in async I/O thread pooled environments like vert.x That's > one of the reasons why sticking a get/put api on the Transaction > instance abstraction instead may make more sense, though I'm guessing > your SynchronizationRegistry is instance per tx rather than a singleton > like the JTA one is, so it may not make much difference which object > carries the functionality for your case? > > Jonathan. > > On 25/10/17 16:25, Steve Ebersole wrote: > > Also, unless I am mistaken `TransactionSynchronizationRegistry#put` > > works on the principle that the "current transaction" is associated with > > the current thread. I absolutely want to stay away from that as an > > assumption here. It simply does not hold true in the JDBC txn case. > > > > On Wed, Oct 25, 2017 at 10:24 AM Steve Ebersole <st...@hibernate.org > > <mailto:st...@hibernate.org>> wrote: > > > > Jonathan, we aren't going to be exposing this or using this > > via TransactionSynchronizationRegistry. Your comment about a > > "dummy" in the JDBC txn case is exactly why. We already have such > > an abstraction : SynchronizationRegistry > > > > On Wed, Oct 25, 2017 at 10:22 AM Steve Ebersole <st...@hibernate.org > > <mailto:st...@hibernate.org>> wrote: > > > > 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? > > > > > > Does it? Nothing in the SPI requires us to store things in any > > specific way. E.g. we can keep just a Map - when we are passed > > a KeyableSynchronization we'd use that key, when we are passed a > > non-KeyableSynchronization Synchronization we'd generate one > > ourselves. > > > > And we cant stop people from every conceivable "silly usage". > > At some point we are professional developers and should be able > > to do the non-silly things ;) > > > > And as far as your "register the thing twice" worry... > > rhetorically, what stops them from calling: > > > > reg.register( "abc", MySync.INSTANCE ) > > reg.register( "123", MySync.INSTANCE ) > > > > Nothing. > > > > > > I'd rather expose a single consistent way: having to make up > > an id > > doesn't seem too inconvenient considering it's an SPI. > > > > > > Well, again, I don't see how KeyableSynchronization is a > > "inconsistent" approach. In fact out of the 2, it is my > preferance. > > > > -- > 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