Locking parent nodes even with lockParentForChildInsertRemov

[tknyziak]

Hi all,

To stress test my JBossCache instance (3.2.0 GA, local mode, synchronous JDBCCacheLoader), I've designed a multi-threaded application which inserts numerous nodes under a common root, e.g. /a/b/c/1, /a/b/c/2, /a/b/c/3, etc. The cache is configured NOT to lock parents for child insert/remove, still, I occasionally get TimeoutExceptions while trying to lock one of the parent nodes, such as a or b, with the MVCCNodeHelper.wrapNodeForWriting being blamed in the stack trace.

Digging into the JBoss Cache sources, I've found out that MVCCNodeHelper.wrapNodeForWriting is being called recursively, and although lockForWriting parameter is false for parent nodes, they still get write-locked, I assume - because they don't exist in the current InvocationContext and are 'createdIfAbsent' - which in turn locks their Fqn's for writing until they're fetched from the DataContainer.

To make long story short, this seems to me like the lockParentForChildInsertRemove = false setting is not effective in my case - parents get locked for writing anyway. Might it be by design? Has anybody stumbled upon this? Or should MVCCNodeHelper.wrapNodeForWriting delegate the recursive call for parent node to wrapNodeForReading (instead of wrapNodeForWriting) if lockParent = false and parent is not in the InvocationContext?

Any help greatly appreciated,

Kind Regards

Tomasz Knyziak

[manik]

Have you tried 3.2.1? There were some issues with certain context flags not being picked up by the MVCCNodeHelper which were fixed in 3.2.1.

[tknyziak]

Sorry for not replying for so long.

I've tried replacing 3.2.0 with 3.2.1 and it didn't help - still, as can be seen on the stack trace, parent nodes get being locked for writing:

org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/node_name] after [1100] milliseconds for requestor [Thread[RMI TCP Connection(46)-192.168.251.104,5,RMI Runtime]]! Lock held by [Thread[RMI TCP Connection(41)-192.168.251.104,5,RMI Runtime]]
 at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:236)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:226)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:226)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:226)
 at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
 at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutDataMapCommand(MVCCLockingInterceptor.java:94)

I don't understand why all parent nodes need to be write-locked - [I assume the direct parent of the inserted node might be locked so a new child information can be updated] - but seems like their absence in the InvocationContext causes a cache-wide lock until they're actually read into it (createdIfAbsent, if you will). Sure I can bump up the timeout, but I suppose it's a work-around rather than a real solution.

Any thoughts?

Kind regards