Affects Version/s: 1.3
Fix Version/s: 1.3.1
Number of attachments :
The root cause of the problem is that the HashSet implementation changed between JDK 1.4 and JDK 1.6.
TransactionLogRecord.calulateCrc32() iterates over the HashSet containing uniqueNames to calculate the CRC32. In JDK 1.4, the order in which unique names are added to the HashSet does no matter: the iteration will always return them in a static order. Under JDK 1.6, the order of the elements during the iteration COULD depend on the insertion order in the HashSet:
In JDK 1.4, iterating this HashSet:
Set uniqueNames = new HashSet();
will always return xyz then abc
In JDK 1.6, we could get abc then xyz or xyz then abc. This depends on the hash value, add order and other internal implementation details.
Since the CRC32 of (abc xyz) is NOT the same as the one of (xyz abc) it could be that during swapJournalFiles() while the TransactionLogRecord are being re-read that they are iterated in another order than the insertion one thus leading to a different CRC32.