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