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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...