Re: [hibernate-dev] Is org.hibernate.cache.spi.OptimisticCacheSource#getVersionComparator obsolete?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team