]
Krzysztof Sobolewski commented on JBCACHE-1449:
-----------------------------------------------
I'm not sure a unit test is possible (or feasible) because it's not deterministic.
Maybe it could be possible with specially crafted listeners that pause two threads at
exactly the right moments (I've done this before) but that would be some work :)
I haven't tested with 3.x due to lack of time (today, at least). I only looked briefly
at the version of this class from trunk and it doesn't look affected (no locks at
all?).
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
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: