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

[Manik Surtani]

<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 at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org