[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