Cache structure - tree

[belaban]

Hi all,

One of the decisions wrt structure of the cache was that a hashmap is inefficient for the JBoss persistence engine, as they use hashmaps of hashmaps of hashmaps, etc, may levels deeps.

So we decided to get rid of the hashmap and instead introduce a tree. This will allow us to map entity beans more easily onto the underlying persitence engine, plus it will reduce the amount of data we need to replicate due to its finer-grained nature.

Such a tree MBean could actually be of use to more than just the persistence engine, e.g. HTTP session replication would benefit as we don't need to replicate an entire attribute (which might be an object, consisting of references to other objects, effectively an object graph).

I'll work this out over the next couple of weeks, and I'll post progress here. The good thing is that JavaGroups altready has such a beast (ReplicatedTree), so I'll copy it over to JBoss and modify/add accordingly (e.g. add XAResource).

More later,

Bela

[marc.fleury]

hey, bela,

I am not totally sold on the tree structure (neither is bill). I mean if we AOP everything then tragging independent state changes is a trivial problem and we don't need individual entries in the cache structure. Can you explain why you decided to that again?

[belaban]

> hey, bela,
>
> I am not totally sold on the tree structure (neither
> is bill). I mean if we AOP everything then tragging
> independent state changes is a trivial problem and we
> don't need individual entries in the cache structure.
> Can you explain why you decided to that again?

I see that tree-structured cache as a valid building block in itself. 2 stages:

#1 Replicated cache
+ can be transient or replicated (async/sync)
+ optional acidity (locking, serializability etc)
- manual put() to track and replicate modifications
+ fast, efficient, no overhead (AOP)

#2 Replicated cache with AOP
+ acidity in interceptors
+ automagic tracking and replication of modifications
- more overhead, e.g. spiking of classes, 1 addtl object/POJO (in case of proxies, e.g. for collections)

I give people a choice of #1 or #2.

Also: I want to be able to provide #1 soon. #2 needs some more discussions with Bill.

Bela