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