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

Gail Badner gbadner at redhat.com
Fri Jun 17 22:11:49 EDT 2016


It is implemented by AbstractEntityPersister, but as of 5.0.9 (using
Infinispan 7.2.5.Final) I see no references to this method in Hibernate
ORM, other than in Javadoc for OptimisticCacheSource#isVersioned  [1] that
says:

"If true, it is illegal for {@link #getVersionComparator} to return null"
[1]

Long story short, if OptimisticCacheSource#getVersionComparator is
obsolete, then there is no reason to create a meaningful Comparator for
Sybase timestamps for HHH-10413.

The long story...

Sybase timestamp can be used as an entity version which is treated as
byte[]. This seems to have caused problems in the past when caching,
because an array does not have a Comparator.

I tried creating a simple comparator that uses Byte#compareTo(Byte), but
unfortunately this does not work for Sybase timestamps, because
Byte#compareTo(Byte)
uses a signed comparison. Sybase timestamps require an unsigned comparison.

I can change the comparator to do unsigned comparisons of byte elements.
One thing to consider is that the same comparator will also be used for
when sorting actions by byte[] IDs.

We discussed earlier that it doesn't make sense to compare IDs that are
arrays. If
OptimisticCacheSource#getVersionComparator is obsolete, then I can simply
use IncomparableComparator#INSTANCE.

If OptimisticCacheSource#getVersionComparator is not obsolete, then is it
worth creating a special BinaryTimestampType that implements
VersionType<byte[]> (instead of BinaryType implementing
VersionType<byte[]>) with a comparator that does unsigned comparisons?

I'm also trying to wrap up HHH-8999, which is also impacted by this.

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/spi/OptimisticCacheSource.java#L24-L25


More information about the hibernate-dev mailing list