On 9 Jun 2011, at 20:10, Manik Surtani wrote:
On 23 May 2011, at 11:49, Mircea Markus wrote:
>>
>>>> 3. Need to think more about this, around implications of correctness of
lock acquisition is reordered. But in terms of algorithm, sorting on identity hashcode
won't work since this will be different on different requestor JVMs.
>>> The algorithm does NOT sort on identity hash code, but on CH. For conflict
resolution (i.e. two keys that have same consistent hash) it can use object's hash
code (default) or allow user to specify a hash code function if needed.
>>
>> Hmm. How does this work with the grouping API, where keys wrapped in a single
transaction would most likely have the same group ID, which is the basis for the hashcode
used in the consistent hash location. This would render any such ordering algorithm
useless...
> That's where the callback for conflict resolution kicks in:
> - if two object have the same consistent hash value
> - call a user function to order the keys
> - this user function, by default, would rely on object's hashcode - this only
works if the key has hashcode overridden - for the JVM reason you mentioned below
And what happens if the object's hashcode is not overridden? Or if a user-defined
hashcode is poor and returns the same value for 2 keys?
In that situation user can
plug-in it's own function. I rely on object's hash only if user hasn't
introduced his own value. If user doesn't do that and object's native haschode is
used then optimisation does not bring any benefit.