Re: [infinispan-dev] DeadlockDetection (DLD) - benchmarks and status

<SNIP /> >> So you do force a lot of deadlocks as a result. And the time taken >> with the non-DLD case would depend on the TM's transaction timeout >> configuration which again would vary. > The Dummy TM does not force rollback based on tx timeout, indeed. > Another important factor it depends on is the lockAcquisitionTimeout. > Still, it's up to the user to benchmark against its very specific > scenario. Sorry yes, I meant lockAcquisitionTimeout in my prev. comment.

>> So as a result I'd be careful about quoting performance increase >> factors in a public blog (although you should definitely blog about >> this as a feature and how it *could* speed up transactions that >> would otherwise timeout). > Point taken. Are you also thinking not to bring up the diagrams? > After all, they the numbers there are real: so by mentioning the > context (intended high collision) and no tx timeout, they are relevant. Well, the numbers are only real given the rate of colliding transactions (versus non-colliding ones) and the lock acquisition timeout that you used. Which is artificial, or at best specific to a certain use case. But either way, not generic enough to publish since it would lead people to believe that they can expect a 500% performance boost when using deadlock detection, and get really pissed off when they *only* get a 25% performance boost since most of their transactions don't collide anyway. :-)

Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org