sorry for the late reply - I'm little bit busy.
Joe Germuska wrote:
Following on with my little thread about using OJB in a data load environment; to re-cap, I'm looking at optimizing batch data updates; doing them by using first-class objects and full OJB adds too much overhead for the purpose. My current thought is to instead do the updates themselves in
I think if I do this I could even invalidate the cache per ID after each write and minimize the risk of dirty reads.
I'm looking for some expert insight here -- from reading the page at "http://db.apache.org/ojb/objectcache.html";, it appears as if the ObjectCacheDefaultImpl is shared, and so is a relatively safe way for me to approach this. This is essentially read-only data except for my batch load, so I do not think the warnings about transaction isolation are a big concern for me right now.
I guess ObjectCache has a clear method too, so I could do the whole batch and then clear the cache. I'm not 100% comfortable with the risk that someone later might change the cache implementation to a "per-broker" implementation and then I wouldn't have any reliable way to clear all the caches.
This shouldn't be a big problem because "per-broker" cache clears its cache after each PB.close/PB.commit/PB.rollback event, thus at the latest after PB.close/PB create sequence the "new" data was used.
I wonder if there should be some API way to do that? Or is the idea that direct cache management is a very exceptional condition and so there isn't any reason to be concerned about this?
hmm, a global cache clear method for all local caches? I think this is a
specific behaviour of the cache implementation. But all proposals are welcome ;-)
regards, Armin
Thanks Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
