[infinispan-dev] DLD continued/optimizing modifications within a tx

Galder Zamarreno galder.zamarreno at redhat.com
Fri Jul 24 06:16:17 EDT 2009



On 07/24/2009 11:43 AM, Mircea Markus wrote:
> Galder Zamarreno wrote:
>>
>> </snip>
>>
>> This is very similar to what we implemented for the coalesced async
>> cache loader actually.
> yes indeed. Would be good to use the same code in both places.
>> I think it makes sense to do so but I have doubts on the ordering that
>> we can impose on the keys and how to make this order be consistent in
>> the cluster. We definitely cannot force keys to be Comparable.
> yes, of course. This functionality should be optional, so a user needs
> to manually enable it. User can also specify a Comaprator, or rely on
> the keys natural order (similar to the way SorteSets works).

Yeah, but do u see users 1st configuring early deadlock detection and 
then realising that their keys are not comparable and re-coding their 
app accordingly? Hmmmm, I'd be put off by that.

In fact, as mentioned on an email earlier on, it'd be even more user 
friendly if ISPN would be able to switch to an early deadlock detection 
manager if it encountered too many TimeoutExceptions or deadlock counts.

So, not sure about this but wonder if you could use the hashCode as an 
order hint. Keys for table must override equals() and hashCode(), so 
since it's recommended that key's hashcode is based on some of the key's 
state, you can assume that a key would return the same hashCode() in 
different machines.

>>
>>>
>>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache



More information about the infinispan-dev mailing list