is it possible to use treecacheaop as the second level cache

[stemeyda]

If not, are there any plans for doing this in the future?

TreeCache performance does not appear to be very robust. I need to replicate a tree that contains roughly 1,000,000 nodes. I need fine grained updating. Any ideas?

[ben.wang]

No, it is not necessary to use TreeCacheAop under Hibernate. The reason being that Hibernate is arelady mapping the object into fields.

What do you mean by not very robust?

-Ben

[stemeyda]

Thanks for the reply.
Maybe I just don't understand how it works. I thought that TreeCache was being used as the second-level cache which updates nodes on a cluster on a per object basis instead of a per field basis. If you are using a cluster with a large number of nodes with a large number of updates, you would not want a per object update on the cluster. The per field mapping in Hibernate is done to the database which is essentially disk io. What I am trying to do is read it off the disk (database) and then maintain a grain leveled update in memory across multiple nodes.

Not very robust. Poor choice of words. Sorry. I believe the term I am looking for is that it does not scale like TreeCacheAop across a cluster. TreeCache will send an update of the entire object if only one field changes.

Thanks again for your reply

[stemeyda]

I understand that when I make a call to EntityManager, a call is made to TreeCache. Hibernate will make a field level change but TreeCache replicates the entire object across a cluster. I want to turn this thing off completely and set up TreeCacheAop as my cache that will replicate the the object at the field level across the cluster. I realize that for every call to my EntityManager I will need to make a call to my TreeCacheAop. I am using the @Clustered annotation.

How do I turn off TreeCache so I can save the memory and network bandwidth for use in the TreeCacheAop? Can I just remove the ejb3-entity-cache-service.xml file and use my own TreeCacheAop property file?

FYI...
I am trying to load up over a million nodes (out of DB using hibernate) in a tree and update every one of these tree nodes every minute. Most of the updates will only be one or two fields out of ~25 fields total for every object.

We have 7 machines in the cluster. Each machine is a dual processor AMD 64 with 8 gigs of ram with a Gigabit backbone and dual nic cards.

[ben.wang]

No, the way Hibernate works (if I remember correctly) is storing to second level cache on a per field based in a Node (that translates to a HashMap in JBossCache). So any field update from HB will only trigger a (key, value) pair update in JBossCache. Still very efficient.

-Ben

[stemeyda]

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?

[mnewcomb]

It seems like these limitations might not apply because Hibernate breaks down the objects to the field level and puts them in the cache. Also, the data being stored is probably at the primitive level.

Is that an appropriate interpretation?

[manik]

Correct, that hibernate breaks down objects when storing them in the 2nd level cache. Not sure about whether they are broken down to primirives though, I'll get back to you on that.