RE: Choosing a cache implementation
At 10:51 AM -0600 1/25/04, Lance Eason wrote: The cache implementation is configurable. OJB can be configured to have a static cache that holds the objects loaded from the db for all time ObjectCacheDefaultImpl, a cache that is limited in scope to a single transaction (actually from the time you get a broker from the pool to the time you return it) ObjectCachePerBrokerImpl, or no caching via ObjectCacheEmptyImpl. There's even some more implementations I'm not sure what do. If you were seeing changes made through SQL not reflected in queries your OJB.properties is probably configured with ObjectCacheDefaultImpl. That explains it. And from looking at the code for class, I can see that clearing the cache returned by a broker when it's an instance of ObjectCacheDefaultImpl will result in clearing the only cache there is, even though access to it is mediated by a broker instance. So I can run a batch database process outside of OJB and call one cache clear method and have my application respect the data loaded externally. This is what I needed to figure out, so thanks everyone! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Choosing a cache implementation
The cache implementation is configurable. OJB can be configured to have a static cache that holds the objects loaded from the db for all time ObjectCacheDefaultImpl, a cache that is limited in scope to a single transaction (actually from the time you get a broker from the pool to the time you return it) ObjectCachePerBrokerImpl, or no caching via ObjectCacheEmptyImpl. There's even some more implementations I'm not sure what do. If you were seeing changes made through SQL not reflected in queries your OJB.properties is probably configured with ObjectCacheDefaultImpl. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Sunday, January 25, 2004 10:29 AM To: OJB Users List Subject: Re: Choosing a cache implementation > >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. Wow, that clears things up; I had some idea that OJB had a "system-wide" cache of some sort, but now I think I understand that the cache is just within a transaction context (or transaction-ish) to avoid cyclical object calls and such. But wait... I know I've had situations where I've made database changes with SQL and don't see them in the JVM runtime until I restart the application. Well, I think I know that. I always thought that was related to the caching. Are there two different aspects of object caching? Am I just confused? Maybe I need to run a few more tests. Armin, I really appreciate your help. Thanks Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Choosing a cache implementation
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. Wow, that clears things up; I had some idea that OJB had a "system-wide" cache of some sort, but now I think I understand that the cache is just within a transaction context (or transaction-ish) to avoid cyclical object calls and such. But wait... I know I've had situations where I've made database changes with SQL and don't see them in the JVM runtime until I restart the application. Well, I think I know that. I always thought that was related to the caching. Are there two different aspects of object caching? Am I just confused? Maybe I need to run a few more tests. Armin, I really appreciate your help. Thanks Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Choosing a cache implementation
Hi Joe, 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]
