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