[jboss-dev-forums] [Design of JBossCache] - Re: state transfer optimizations - persisitng state with JDB

[manik.surtani@jboss.com]

I think the biggest problem will be the in-memory merge and OOMs.  One of the primary reasons to use a cache loader is because you have more state in the cache than memory.  :-)

Lets think why we bother with the !exists test in memory first.  If this is just an optimisation so we don't have to write the state to the DB when the state already exists, then in this case the optimisation doesn't help but hinder.  We should just write *everything* to the CL.

The other reason why you may not want to write everything to the CL is if you are using passivation.  Then, stuff in-memory should not be in the CL.

So, perhaps this is what we need to do (if we are using a JDBC cache loader only):

1.  If !using passivation, write all state to the DB, regardless of whether it exists in memory or not.  
2.  If using passivation, when attempting to deserialize state to put into your batch, ignore statements which pertain to Fqns that are in memory.

I agree about having configurable batch size limits, with perhaps a 1k batch size default.
  

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155321#4155321

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155321