"rino_salvade" wrote : We experienced a similar problem when we tried to access the same node that was modified again within the treecache listener (I do not know if that is the case with you). |
This is not recommended, and you will almost always run into problems, especially in the distributed case. There is a JIRA issue open for this: http://jira.jboss.com/jira/browse/JBCACHE-49 anonymous wrote : | To our opinion the problem is that the lock and unlock interceptor use the thread as key for their lock table and not the method. | Note that this is only the case if no transaction is active for the current thread. anonymous wrote : | This causes the problem that the lock table becomes empty but the node still maintains the lock. | Come again, didn't understand what you said here ? anonymous wrote : | To solve the problem we changed the lock and unlock interceptors and made the method the key of the table. With this the problem went away. What if multiple threads are calling the same method concurrently ? Then you would grant the lock on a given node to both threads ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3893009#3893009 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3893009 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
