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

[Mircea Markus]

Galder Zamarreno wrote:
>
>
> 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.
yes, for this scenario this approach would not work. But more generally, 
in many scenarios the cache would be used by users with simple keys 
(Strings for eg) and we can do better for them.
At a second thought, even for the users that have not comparable keys, 
they still can provide an Comparable instead of re architecture.
Okay, this sounds like some trouble for the user, so what I'll do is run 
a simple benchmark to check weather we have a performance increase that 
would worth the effort.
>
>
> 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.
Interesting, I don't see why this won't work. There might still be 
deadlocks if we have equals hashes (k1.hashCode() == k2.hashCode()) so 
they still might be processed by different tx in different order. Still 
the chance for equal hashCode *should* be quite small.
> 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.
>
>>>
>>>>
>>>
>>
>