July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBCACHE-173) Locking model when pojo is multiple referenced

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-173?page=comments#action_12340062 ] Ben Wang commented on JBCACHE-173: ---------------------------------- To be more canonical, basically every pojo will be stored under the _JBOSS_INTERNAL_ region (even if there is not sub-object). This is needed such that I may have, cache.attach(id1, address); cache.attach(id2, joe); where address is also part of joe. So everything is represented by a PojoReference under the regular ID. That is the external facing reference value that a user will see. This should be transparent. However, for visualization purpose (e.g., Cache IDE), we will need some trick to do it. That is, the normal GUI won't work anymore. In addition, all the internal id is generated by GUID that should be unique among the cluster. > Locking model when pojo is multiple referenced > ---------------------------------------------- > > Key: JBCACHE-173 > URL: http://jira.jboss.com/jira/browse/JBCACHE-173 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: POJOCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Under the new PojoCache, when a pojo is multiple referenced (let's say a pojo, Joe), it will be located under JBOSS_INTERANL node while leaving the original with a fqn/id reference. > In terms of locking, there are various implications. > 1. If we are modifying Joe under a tx context directly, the locking will be done under the JBoss_INTERNAL node. As a result, consistency is warranted. > 2. If Joe is part of a sub-object, say, a UserState object that has a Person Joe reference. Then, a tx context under that UserState obejct is not locking on Joe (since it has been moved to under JBOSS_INTERNAL, and therefore not under the same fqn sub-tree). -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-268) PojoCache InternalDelegate can return incorrect AOPInstance object

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-268?page=all ] Ben Wang updated JBCACHE-268: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > PojoCache InternalDelegate can return incorrect AOPInstance object > ------------------------------------------------------------------ > > Key: JBCACHE-268 > URL: http://jira.jboss.com/jira/browse/JBCACHE-268 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: POJOCache > Reporter: twundke > Assigned To: Ben Wang > Fix For: 2.0.0 > > > The getAopInstance(Fqn) method of InternalDelegate currently uses a cache.peek() call to find the AOPInstance object for an FQN. However, I've come across a situation where multiple calls to this method for the same FQN will return different AOPInstance objects. > To be honest, I'm not sure of the exact situation in which this occurs as I haven't delved deep enough. However, the basic idea is that I have an object graph in the cache, all hanging off one particular root-level object. I then do a fairly major addition/update to a number of children, but don't specifically update the root-level object. After this update I find that InternalDelegate returns a new instance of the AOPInstance class for the root object's FQN, which has now lost its POJO reference etc. This in turn forces a re-creation of the root-level object, which loses a number of transient references that I have set. > Note that my object graph has a number of circular references back to this root-level object, so I suspect that the AOP machinery is for some reason updating this object during the update of the children, thereby losing the original AOPInstance reference. > I've put in a quick fix locally that caches references to AOPInstance objects in a HashMap, which follows the idea suggested in the comment for the method. This solves the issue. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-399) CachedMapImpl doesn't store key objects

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-399?page=all ] Ben Wang updated JBCACHE-399: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > CachedMapImpl doesn't store key objects > --------------------------------------- > > Key: JBCACHE-399 > URL: http://jira.jboss.com/jira/browse/JBCACHE-399 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: 1.2.4SP1 > Reporter: twundke > Assigned To: Scott Marlow > Fix For: 2.0.0 > > > The current implementation of CachedMapImpl forces all keys to be string values. In CachedMapImpl we have: > public Object put(Object key, Object value) > { > return cache_.putObject(AopUtil.constructFqn(getFqn(), key), value); // removed try/catch for brevity > } > The current implementation of AopUtil.constructFqn() essentially calls key.toString(). Therefore, calling keySet() on the map will always return a set of String objects, which is usually not what the user intended. > I have a fix that stores key objects under a "key" FQN, and value objects under a "value" FQN. So, rather than calling getFqn() I now call either getValueFqn() or getKeyFqn() as appropriate. keySet() now acts the same way as values(), returning the correct object type for each key. This also requires a change to CollectionClassHandler.collectionObjectPut(), which now directly uses the Map.put() method to pre-populate the map, rather than directly adding entries to the cache. > Note that the unit tests currently only use String objects as keys, so they all pass. A few more unit tests need to be added to cover testing key types. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-110) PojoCache overriding toString or hashCode can trigger stack overflow

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-110?page=all ] Ben Wang updated JBCACHE-110: ----------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > PojoCache overriding toString or hashCode can trigger stack overflow > -------------------------------------------------------------------- > > Key: JBCACHE-110 > URL: http://jira.jboss.com/jira/browse/JBCACHE-110 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: 1.2 > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion. > Kabir has done it in: > org.jboss.aspects.dbc.DesignByContractAspect -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-643) Tx undo during rollback exception needs to go into an interceptor

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-643?page=all ] Ben Wang updated JBCACHE-643: ----------------------------- Component/s: PojoCache Fix Version/s: 2.0.0 (was: POJOCache) > Tx undo during rollback exception needs to go into an interceptor > ----------------------------------------------------------------- > > Key: JBCACHE-643 > URL: http://jira.jboss.com/jira/browse/JBCACHE-643 > 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 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Currently, we handle the tx rollback in two layers: underlying TreeCache for put/remove and PojoCache for interceptor undo. However, for complicated object graph reference counting, it may have problems. A proper way is to consider using interceptor based and perhaps undo modification list as in TreeCache. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-85) PojoCache object event listener

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-85?page=all ] Ben Wang updated JBCACHE-85: ---------------------------- Fix Version/s: 2.0.0 (was: POJOCache) > PojoCache object event listener > ------------------------------- > > Key: JBCACHE-85 > URL: http://jira.jboss.com/jira/browse/JBCACHE-85 > Project: JBoss Cache > Issue Type: Feature Request > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: 2.0.0 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Need to add a TreeCacheAop object event listener. Currently we have TreeCache listener to listen for individual node event. We need to listen the event at the object level instead. User may not be interested to listen at the node level. > We should have events for: > * Object level > * Field level > 1. We will need to define a PojoCacheListener that has all these callbacks. > 2. We should use annotation for user to denote interested points, e.g., a la EJB3 style call back > Class Pojo > { > int key; > @preCreated(pojoEvent) > @preModified(pojoEvent) > void someHandler(); > } > where > Interface preModified { > getPojoEvent(); > } -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-586) Use new PojoCache APIs to replace the exisiting pojo operations

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-586?page=all ] Ben Wang updated JBCACHE-586: ----------------------------- Component/s: PojoCache Fix Version/s: 2.0.0 (was: POJOCache) > Use new PojoCache APIs to replace the exisiting pojo operations > --------------------------------------------------------------- > > Key: JBCACHE-586 > URL: http://jira.jboss.com/jira/browse/JBCACHE-586 > 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 > > > In 2.0, we should deprecate the put/remove/getObject apis and opt for APIs such as attach, detach, and find. This is basically an api switch. But it also a step towards a new collection of pojo manager apis. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-699) PojoCache create a modified Observable aop aspect pattern

by Ben Wang (JIRA)

PojoCache create a modified Observable aop aspect pattern --------------------------------------------------------- Key: JBCACHE-699 URL: http://jira.jboss.com/jira/browse/JBCACHE-699 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 We have created a modified observable aop aspect under org.jboss.cache.pojo.observable. We need this becuase the original one didn't provide: 1) modified field information (only that it has been modified) 2) It does not distinguish pre- and post- modification events. Only emit when the field value has been changed. This pattern is needed for the pojo field event notification mechanism. -- 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

19 years, 10 months

1
2
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-673) Refactor PojoCache to use TreeCache as a delegate

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-673?page=all ] Ben Wang resolved JBCACHE-673. ------------------------------ Resolution: Done This is mostly done except some integration work. > Refactor PojoCache to use TreeCache as a delegate > ------------------------------------------------- > > Key: JBCACHE-673 > URL: http://jira.jboss.com/jira/browse/JBCACHE-673 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Components: PojoCache > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: POJOCache > > Original Estimate: 1 week > Remaining Estimate: 1 week > > In release 2.0, we will use the underlying cache as a delegate instead of sub-classing. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-268) PojoCache InternalDelegate can return incorrect AOPInstance object

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-268?page=all ] Ben Wang resolved JBCACHE-268. ------------------------------ Resolution: Won't Fix Since there is a new object mapping internally for 2.0, this is no longer an issue (or nonrelevant). > PojoCache InternalDelegate can return incorrect AOPInstance object > ------------------------------------------------------------------ > > Key: JBCACHE-268 > URL: http://jira.jboss.com/jira/browse/JBCACHE-268 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PojoCache > Affects Versions: POJOCache > Reporter: twundke > Assigned To: Ben Wang > Fix For: POJOCache > > > The getAopInstance(Fqn) method of InternalDelegate currently uses a cache.peek() call to find the AOPInstance object for an FQN. However, I've come across a situation where multiple calls to this method for the same FQN will return different AOPInstance objects. > To be honest, I'm not sure of the exact situation in which this occurs as I haven't delved deep enough. However, the basic idea is that I have an object graph in the cache, all hanging off one particular root-level object. I then do a fairly major addition/update to a number of children, but don't specifically update the root-level object. After this update I find that InternalDelegate returns a new instance of the AOPInstance class for the root object's FQN, which has now lost its POJO reference etc. This in turn forces a re-creation of the root-level object, which loses a number of transient references that I have set. > Note that my object graph has a number of circular references back to this root-level object, so I suspect that the AOP machinery is for some reason updating this object during the update of the children, thereby losing the original AOPInstance reference. > I've put in a quick fix locally that caches references to AOPInstance objects in a HashMap, which follows the idea suggested in the comment for the method. This solves the issue. -- 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

19 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2006