[hibernate-dev] Is org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator obsolete?

[Radim Vansa]

On 06/18/2016 06:14 PM, Steve Ebersole wrote:
> TIMESTAMP is a deprecated synonym for the TSQL rownumber datatype, at least
> on SQL Server.  Not sure specifically about Sybase.  So I'll use "rownumber"
> here...
>
> As we discussed in HipChat yesterday OptimisticCacheSource was added a long
> time ago to facilitate leveraging JBossCache's MVCC support for versioned
> data.  The idea was to allow JBossCache to reuse a versioned entity's
> version as its MVCC version via the comparator.
>
> JBossCache is of course no more, now morphed into Infinispan.  To my
> knowledge, Infinispan does not have the same MVCC support if any.  Either
> way, hibernate-infinispan does not support MVCC in the Infinispan cache by
> leveraging the entity version.  Radim, Galder - is this something we want
> to consider?

Versions can remove the need to lock some entries. At this point the 
comparison is used only in the nonstrict read-write access strategy, and 
it does not use Infinispan MVCC (I can't recall exactly why, probably it 
was more convenient to have the version in entry value than in metadata, 
as there's really no OOTB support).

One reason this is not leveraged more is that it imposes limitation on 
the types of entries; though it can be transparent to the user, the 
effort is still reduced by the fact that it's only a portion of use cases.

>
> Depending on the version (and I forget the exact version this changed) the
> role played by OptimisticCacheSource is actually now handled by
> org.hibernate.cache.spi.CacheDataDescription.
> So that is one of the reasons you do not find any uses of
> OptimisticCacheSource#getVersionComparator.  Do a usage search for
> CacheDataDescription#getVersionComparator instead.
>
> Same question, different contract.

Never seen OptimisticCacheSource, CDD was there at hand. Infinispan does 
not need to keep that in API.

>
> Some of the cache providers do leverage this version comparator (via
> CacheDataDescription#getVersionComparator) for read-write locking.  So
> really the question is whether we want to allow the combination of:
>
>
>     1.  these cache providers with those access strategies using the version
>     comparator
>     2. versions based on TSQL rowversion datatype.
>
> Aside from a general dislike of versions based on TSQL rowversion datatype
> (for many reasons), there is no fundamental reason to not allow it as a
> comparator (provided we find the right comparison algorithm).  If you have
> found the secret incantation for writing a proper Java Comparator based on
> the TSQL rowversion datatype, then I think we should just implement that.

If DB has that info, it's fair that Cache can have that, too. I would 
keep the support, though it does not have to have 100% coverage on the 
possible datatypes (if there are 2% that are too complex to implement).

Radim

> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team