Re: [hibernate-dev] SynchronizationRegistry: expose read (lookup) operations?

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 <steve(a)hibernate.org <mailto:steve@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 <steve(a)hibernate.org <mailto:steve@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.