so you have some form of implicit cleanup that de-registers Synchronizations when the transaction finishes, or do they stay registered and re-fire for each tx on the connection?
As to the multiple registration semantics, IIRC the arjuna code allows the same Synchronization to be registered multiple times and in such case it will be called multiple times too. No reason you need to follow that model unless you're delegating to the tx engine though. If you go for 'we always generate the key for you', then calling String id = sr.register(sync) twice could just give you back the same id. Downside is you need to store that id someplace, which misses the point of allowing a fixed constant as the key. I'm rather assuming that's the requirement here, since if you're needing to keep and pass around a uniq key then you may as well just pass around the sync object itself? Anyhow, is a key of any form necessary for that use case? Could retrieval just be sr.getSynchronizationsOfType(thing.class) to match on class/interface, which should be all that's needed to find e.g. the cache/search/whatever synchronization. Not having a key means saves having to define how it behaves. Lookup maybe slower if you're going to support polymorphism though, but the number of Synchronizations per tx should be small. Jonathan. On 25/10/17 16:39, Steve Ebersole wrote: > 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 <mailto: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> > > <mailto: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> > > <mailto: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 > -- 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
