]
Manik Surtani commented on JBCACHE-1449:
----------------------------------------
Timeout exceptions on MVCC on trunk?
Small lock confusion in CacheLoaderInterceptor
----------------------------------------------
Key: JBCACHE-1449
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1449
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Cache loaders
Affects Versions: 2.2.1.CR1
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Fix For: 3.1.0.GA
I was doing another torture-test of one of my components based on JBoss Cache and noticed
mysterious "can't lock node" exceptions. The test is very simple: 5 threads
are trying to retrieve one node's key, 5 other threads try to delete it.
Long story short, I think the result is one the smallest fixed I've ever seen :)
Index: src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java
===================================================================
--- src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (revision
6986)
+++ src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (working
copy)
@@ -245,7 +245,7 @@
{
NodeSPI n = dataContainer.peek(fqn, true, true);
Object lockOwner = lockManager.getLockOwner(ctx);
- boolean needLock = n != null && !lockManager.ownsLock(fqn, lockOwner);
+ boolean needLock = n != null && !lockManager.ownsLock(n, lockOwner);
boolean mustLoad = false;
try
{
It seems that when the node (n) is deleted, the lockManager checks some different nodes
map, when it uses the node's FQN, than is later checked on line 252, where it tries to
read-lock the node (and fails, because it's already locked by pessimistic locking
interceptor).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: