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

Manik Surtani wrote: > <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. In this case lowering lock acquisition timeout would result in rollbacks of non-deadlocked txs as well, so not sure the overall outcome is better.

> >>> 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. :-) What about a pool of 50 objects? Or 100?