[JBoss JIRA] Created: (JBCACHE-707) PojoCache to aspectize JDom classes
by Ben Wang (JIRA)
PojoCache to aspectize JDom classes
-----------------------------------
Key: JBCACHE-707
URL: http://jira.jboss.com/jira/browse/JBCACHE-707
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: POJOCache
This is suggested by Bela during a customer visit. Idea is the customer is using JDom internally to store the documents such as mail, fax, email, parcel, and the like. However, for clustering purpose, each single update on document element would require replication of the whole document. Not a very efficient process.
If PojoCache can aspectize JDom classes then fine-grained replication can be done transparently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 7 months
[JBoss JIRA] Created: (JBCACHE-712) PojoCache needs a new tutorial gui
by Ben Wang (JIRA)
PojoCache needs a new tutorial gui
----------------------------------
Key: JBCACHE-712
URL: http://jira.jboss.com/jira/browse/JBCACHE-712
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: 2.0.0
Currently, the gui for PojoCache just display the internal cache node straight out so user can observe the field-level change. This however may not work under 2.0 since the internal ojbect model has changed.
One possiblity is the user will have to inspect the internal area as well (that is clouded by a random GUID though). The other one is we add intelligence to the GUI such that display is for object view.
This can relate to the CacheIDE as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBCACHE-697) PojoCache Collection sub-field when detached will revert back to the original reference
by Ben Wang (JIRA)
PojoCache Collection sub-field when detached will revert back to the original reference
---------------------------------------------------------------------------------------
Key: JBCACHE-697
URL: http://jira.jboss.com/jira/browse/JBCACHE-697
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: PojoCache
Reporter: Ben Wang
Assigned To: Ben Wang
Fix For: POJOCache
In PojoCache 1.4, when a Pojo has a Collection sub-object, it will dynamically replace the reference with a corresponding ClassProxy one such that we can intercept the Collection APIs. This is in attached state. When the POJO is detached, we would simply keep the ClassProxy reference but rather point the interceptor to the original reference. This works fine except when the POJO is meant for remoting as ClassProxy is not Serializable and not for direct manipulation.
The solution is when a POJO is detached, it will dynamically swap back the original reference and discard the ClassProxy. This way, it is semantically similar to a regular POJO as well. There will be no issue of Remoting, as an example.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 8 months
[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails
by Ben Wang (JIRA)
CacheLoader passivation/activation produces recursive exception when loader.remove fails
----------------------------------------------------------------------------------------
Key: JBCACHE-710
URL: http://jira.jboss.com/jira/browse/JBCACHE-710
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.0
Reporter: Ben Wang
Assigned To: Manik Surtani
Priority: Critical
Fix For: 2.0.0
I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened:
In ActivationInterceptor.java, we have:
if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) {
if (n.hasChildren()) {
if (allInitialized(n)) {
log.debug("children all initialized");
remove(fqn);
}
} else if (loaderNoChildren(fqn)) {
log.debug("no children " + n);
remove(fqn);
}
}
}
}
return retval;
}
private void remove(Fqn fqn) throws Exception {
loader.remove(fqn);
cache.notifyNodeActivate(fqn, false);
if (cache.getUseInterceptorMbeans()&& statsEnabled)
m_activations++;
}
problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g.,
cache.get(fqn, key)
to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion.
A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 9 months