On 25 October 2017 at 17:13, Jonathan Halliday <jonathan.halli...@redhat.com> wrote: > > 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?
I agree, that's what I'd want to avoid - at least in the Hibernate Search case. > 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. That would work for me, and I wouldn't need polymorphism. Exact class will do just fine. So this approach might allow to keep the registration API as-is, but if we allow to register multiple instances of the same class the retrieval would return a random instance. That's not a problem for my use case and could be addressed with javadoc, probably a nice compromise. Incidentally maps keyed by Class are very efficient so that's nice too. Would it suffice for you too Radim? Since noone else ever asked for such a feature I think the two of us represent the users population :) Thanks, Sanne > > 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
