Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I have a beginner's question about storing object graphs in caches.

Suppose there's a many-to-many relationship between Teams and Members, so
Code:

 class Team {
   String teamId;
   List<Member> members;
   // the rest...
 }
 
 class Member {
   String memberId;
   List<Team> teams;
   // the rest...
 }

If teams cache contains Team objects and members cache contains Member objects, how do I insure that the dependent teams and members point to the objects in the cache instead of just "hanging off"?

So the members of a team in the teams cache should be references to members in the members cache. Is this something that needs to be maintained manually?

The only way I can see how to do this if the classes are like so.
Code:

class Team {
    String teamId;
    List<String> memberIds;
    // the rest...
  }
  class Member {
    String memberId;
    List<String> teamIds;
    // the rest...
  }

If the question isn't clear, I'd be happy to elaborate further.

Mike

I guess you want to make sure that changes to Member instances accessed through a Team instance from the Team cache reflect to the "same" instances accessed through the Member cache, right ?
If so, you'd need to store something else in those caches... You could have a cache decorator being responsible for the transformation on read/write to the cache, so that in code, it would just look as if plain Team/Member graphs are being access/stored everytime.
Basically, as Hibernate does it btw or pretty close to cache ResultSets, you'd store dehydrated versions of the say Team instance in the cache, an Object[] with all the values on the different fields, including an array of all memberId. It'd then wire the Team instance with the according Members from the Member Cache.
You could try to cache a datastructure that is less "intensive" at read/write time, but you need to watch out for concurrent access to hydrated instances, should you expose anything that's in the cache to the application code...
HTH!

Hey Alex, thanks for replying.

...you want to make sure that changes to Member instances accessed through a Team instance from the Team cache reflect to the "same" instances accessed through the Member cache, right ?

Pretty much. If a member object is updated, I only want to update it in the members cache, not in every team that has this member.

You could try to cache a datastructure that is less "intensive" at read/write time

Is the second code block in my original question an example of such data structure? Only dependent object id's are stored, not an object itself.

On a different note, search of the forum didn't find anyone interested in this issue, which is pretty basic in my scenario. So I wonder if Ehcache is a good match for what I'm trying to do, which is this:
I'd like to use Ehcache as a general purpose client side object repository.
So if a client needs any data, it's always in one of the caches. In the meantime, the caches on the various clients are synchronized and kept up to date by some means, e.g. via CRUD JMS messages through a central server.
Do you think Ehcache could be used in this design?
(I realize this is a different question that maybe should be asked in a different thread...)

Mike

Hi i have a similar use case, very interested to hear an answer.

Mike,
I guess holding a reference to all PK of the other object in the association would be one way. You could also have both (PK & actual objects) in there and populate the say Member list on gets within that decorated cache and clear it on puts.
Yet another way would be to have a single cache with the objects keyed by teamPK, and another one matching memberPK to teamPKs, so that when asked to retrieve a member, it resolves one of his teams, get it from the cache and hand the member object back a the root ref to the graph.
Both of these approaches don't act as a "copy on read/on write" though. So, depending on the deployment you are using, you might have to make this object graph mutable in a thread safe way as they both require maintenance of multiple data-structures, which won't be atomic operations.
These are just ideas, depending on your use-case, one, more or none might be the right solution though :/