[JBoss JIRA] Created: (JBCACHE-1553) Potential possibility to avoid some (most?) locking in CacheLoaderInterceptor.loadChildren()
by Krzysztof Sobolewski (JIRA)
Potential possibility to avoid some (most?) locking in CacheLoaderInterceptor.loadChildren()
--------------------------------------------------------------------------------------------
Key: JBCACHE-1553
URL: https://jira.jboss.org/jira/browse/JBCACHE-1553
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 3.2.1.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: LoadChildrenChildLockingTest.java
We create new nodes in memory with "children loaded" flag always set to false, because we cannot efficiently check whether this is a purely new node or it exists in evicted state. This flag can be happily set to false for a very long time, until someone calls getChildrenNames() (or similar); at this moment CacheLoaderInterceptor decides it must load the node's children from the cache loader, in case there are some that weren't accessed recently enough for them to be activated. In the process, it locks the node *and* all the children nodes.
I think the locking of children can be avoided if the child was already in memory. I filed this as a bug because it caused real problems in our application (with locking in unexpected moments and places).
I'm attaching a test case and a patch that worked for me, but, as usual, causes unknown collateral damage :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
- 1
- 5
[JBoss JIRA] Created: (JBCACHE-1552) Cache.removeNode(Fqn) does not affect cache loading until commit
by Krzysztof Sobolewski (JIRA)
Cache.removeNode(Fqn) does not affect cache loading until commit
----------------------------------------------------------------
Key: JBCACHE-1552
URL: https://jira.jboss.org/jira/browse/JBCACHE-1552
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 3.2.1.GA
Reporter: Krzysztof Sobolewski
Assignee: Manik Surtani
Attachments: DeletedNodesLoadTest.java
A sequence of operations like this:
// we have something in the cache
cache.put(fqn, key, value);
// but it's not in memory right now
cache.evict(Fqn.ROOT, true);
tm.begin();
// I want to remove it
cache.removeNode(Fqn.ROOT); // returns false, BTW
// and expect it to not be there
assert cache.get(fqn, key) == null; // fails
tm.commit();
assert cache.get(fqn, key) == null; // passes if no get() in transaction
The problem is that the failing get() loads the node from cache loader. The second assertion passes, because the modification is recorded in the transaction and carried out on the cache loader during commit (it is also replicated across the cluster). But otherwise the cache does not notice the remove().
I think it can also lead to inconsistency between cache loader and transient state (the get() in transaction loads to memory and commit removes from cache loader).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months
- 2
- 2
[JBoss JIRA] Created: (JBCACHE-1550) Migrate the project to magnolia
by Mircea Markus (JIRA)
Migrate the project to magnolia
-------------------------------
Key: JBCACHE-1550
URL: https://jira.jboss.org/jira/browse/JBCACHE-1550
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Mircea Markus
Assignee: Manik Surtani
Email from rkozmik(a)redhat.com:
---
I already talked with Mircea about migrating those JBoss Cache pages and wanted to check with you when you get back. Apparently you caught me first. ;-)
Usernames are currently created per project and can be shared among teammates. In future we will replace them with standard jboss.org accounts but it's not a priority for now as migration of projects is.
So, I created a project space for JBoss Cache in Magnolia and you can login at http://jboss.org/author using:
<look within email for this>
Please remember that we have a great guide about creating project sites in Magnolia - http://jboss.org/help/projectpageguide/
In case of any issues feel free to email me or catch on AIM/ICQ: unibrew. Also you can try IRC: #jbossorg where myself or Jozef Chocholacek(jchochol) should be.
----
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
- 1
- 1