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> 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> > 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. >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev