Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

How to integrate with EclipseLink/TopLink second cache or create third level cache?

EclipseLink is the open source version of Oracle TopLink.

The goal is to call less often the database, at least when the query is by primary key. EclipseLink does have changeset propagation but this is sending the new instances or updated instances to all servers, even if they never use them and will never case about them.

So how could I use Terracotta instead of EclipseLink change propagation?

I could probably use EclipseLink invalidation with some sort of third level cache handled by Terracotta.

First, I thought it will be more efficient to target the second level cache, but TopLink is doing a ton of locking for each transaction that execute, and the second level cache is not an open API, and the locks are custom and fragile by design. The locking code doesn't use only native Java synchronization, but a couple of specialize classes based on CacheKey.

So, the drawback of using a third level cache is that in a scenario where the object in the third level cache are not too much duplicated in the other servers (like because of affinity), I will end-up with doubling the memory usage taken by the second level cache when creating this third level cache in the best case scenario.

The good side is that seems easy to implement.

By the way, EclipseLink second level cache are real POJO with references to their children. However, some references may not have yet been "lazy" loaded.

The algorithm could be like this:
- check third level cache for existing object before calling the db (but really what I want is "find me one matching instance in the second level cache of any server")
- when add or update second level cache, do the same to the third level cache
- reuse TopLink API about changeset to only update modified field on the third level cache object updated so that less changes are propagated

Please optimize logic. You probably see something similar all the time.

I have some concerns about how Terracotta can implement the lifecycle and optimize the work to be done. I would like to know:
- how to avoid having too much of third level cache instances around, because really, when I'm looking for a specific instance in the third level cache I just need one in any clients or Terracotta server. I don't have much benefit to keep more than one instance around. So the instances should disappear fast from my clients but stay on Terracotta server.
- ideally the single third level cache instance should go away only after all equivalent instance of the second level cache are garbaged. EclipseLink is using a mix of hard/soft/weak references so I would like to match lifecycle of the third level cache with the one of the second level cache. Maybe I could have a "observer" object that reference the second level cache object with weak reference, then notify Terracotta server, when it's gone. Then if Terracotta server doesn't find any reference, it can garbage the third level cache instance?
- How a Map<Class,Map<Key,PojoInstances>> are optimized? At the least I don't expect any PojoInstances be migrated to my clients while searching in first and second level map. Does all the Class and Map<key, null> must be copied to the client to do the search?

stardif,

The scope of the problem you are trying to solve with Terracotta might be better addressed through a more involved conversation. I think we have sent you a reply offline.

Thanks!