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