[
https://issues.jboss.org/browse/ISPN-2491?page=com.atlassian.jira.plugin....
]
Radim Vansa closed ISPN-2491.
-----------------------------
Resolution: Out of Date
Locking is not ordered by hashcodes anymore. The locks on each primary are requested in a
synchronized block, introducing order on the requests. The locks are fair, and therefore
two transactions sharing a set of keys will have the subset served in the same order.
Order of locks in optimistic locking is not strict
--------------------------------------------------
Key: ISPN-2491
URL:
https://issues.jboss.org/browse/ISPN-2491
Project: Infinispan
Issue Type: Quality Risk
Components: Transactions
Affects Versions: 5.1.8.Final, 5.2.0.Beta3
Reporter: Radim Vansa
Priority: Minor
In OptimisticLockingInterceptor, the keys are ordered according to their hash. However,
the hashes can still collide, which may result in a deadlock if two keys with identical
hash (only 32-bit) are sorted to different order. We should try to check if the keys are
Comparable or let user provide some comparator class in config, and use the compare of
hash only as the last resort.
In all cases, a warning should be emitted if the compare operation had non-strict result.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)