On 10/26/2017 01:23 AM, Sanne Grinovero wrote: > 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 :)
My case was already solved by the CacheTransactionContext, and it seems more convenient than doing any lookups. But for general use I find by-class lookup more appealing than registering with a custom key. The registrar can always use some private class; it's not like unrelated components would do lookup of others' synchronizations. Radim > > 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 -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev