Quote from the TreeCacheAop documentation: In addition, it (TreeCache) has additional known limitations: ? User will have to manage the cache specifically. E.g., when an object is updated, a user will need a corresponding API to update the cache content. ? If the object size is huge, even a single field update would trigger the whole object serialization. Thus, it can be unnecessarily expensive. ?The object structure can not have a graph relationship. That is, the object can not have sub-objects that are shared (multiple referenced) or referenced to itself (cyclic). Otherwise, the relationship will be broken upon serialization. For example, Figure 1 illustrates this problem during replication. If we have two Person instances that share the same Address , upon replication, it will be split into two separate Address instances (instead of just one).
Do these limitations not apply when used as a clustered second-level TreeCache? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3900620#3900620 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3900620 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
