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

[Steve Ebersole]

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 at 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 at 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.
>>
>>