Hi Radim,
Definitely something to keep in mind, mind creating a jura for it?
On 9 Nov 2012, at 09:24, Radim Vansa wrote:
> Hi,
>
> 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.
> The locks would time-out, but shouldn't we at least 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? (and in all cases emit warning
> into log if the compare operation had non-strict result).
> It's a minor problem (considering other current locking issues), but I
> wouldn't want to investigate why such deadlock happened :)
> Btw., in OLE.visitPrepareCommand the log.tracef("Using lock reordering, order
> is: %s", orderedKeys); does not work, only the first key is printed out.
>
> Radim
>
> -----------------------------------------------------------
> Radim Vansa
> Quality Assurance Engineer
> JBoss Datagrid
> tel. +420532294559 ext. 62559
>
> Red Hat Czech, s.r.o.
> Brno, Purkyňova 99/71, PSČ 612 45
> Czech Republic
>
>
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
