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

[Mircea Markus]

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