Is the code you're using to trigger this on github somewhere? The Enterprise lock manager is new, so it could be you've found a case that triggers a bad code path.
Most likely, however, the problem is as follows: The Enterprise version of Neo4j has an alternative lock manager than the Community version, meant to provide scalable locking on high-CPU-count machines. The Enterprise Lock Manager uses a deadlock detection algorithm that does not require (much) synchronization, which gives it some very desirable scalability attributes. The drawback is that it may sometimes detect false-positives. This normally does not happen in production usage, but becomes evident in stress testing individual operations. These scenarios see much lower churn in CPU cache invalidation, which the enterprise lock manager needs to communicate across cores. As a deadlock detection error is a safe-to-retry error and the user is expected to handle these in all application code, since there may be legitimate deadlocks at any time, this behavior is actually by design to gain scalability. /j On 8/12/14, Mike Holdsworth <[email protected]> wrote: > I run a ton of tests against Neo4j community for both basic functionality > and stress testing concurrency behaviour and schema changes. They're all > passing nicely thank you. I thought I'd have a look at how they run against > > the enterprise edition and was surprised to experience ~14 failures with > the following representative error message: > > org.neo4j.kernel.DeadlockDetectedException: ForsetiClient[42] can't acquire > > UpdateLock{objectId=107277620, refCount=1, holder=ForsetiClient[44]} on > SCHEMA(0), because holders of that lock are waiting for ForsetiClient[42]. > Wait list:SharedLock[ForsetiClient[44] waits for [42, 44, ], ] > at > org.springframework.data.neo4j.support.query.CypherQueryEngineImpl.query(CypherQueryEngineImpl.java:61) > at > org.springframework.data.neo4j.repository.query.GraphRepositoryQuery.dispatchQuery(GraphRepositoryQuery.java:117) > > > Are there key differences to the way that locks are managed between the > editions? Secondly, why would the enterprise edition be more likely to > deadlock than community? I didn't notice anything in the documentation that > > would lead me to consider it to be a configuration issue. > > 2.1.3 embedded, SDN. > > -Mike > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Jacob Hansson Cell # : +46 (0)708 14 59 46 Home # : +46 (0)42 34 31 25 -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
