Hi folks, >There is still caching, but is ignored.
So, wouldn't ObjectCacheEmptyImpl be just as good in this situation, or am I missing something? -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 5:00 AM To: OJB Users List Subject: Re: Cache question [EMAIL PROTECTED] wrote: >>To avoid problems you should use Optimistic Locking (OL) to avoid write >>conflicts. > > > How do you set it up ? see http://db.apache.org/ojb/repository.html#field-descriptor for a description of the locking attribute. There are several samples in the repository_junit.xml. > >>And if you don't want to handle many OL exception you can set >>refresh="true" for all persistent classes. > > > Which means there will be no caching at all. There is still caching, but is ignored. cheers, thomas > Regards, > > Patrick Reyes > > > > > Thomas Mahler > > <[EMAIL PROTECTED] To: OJB Users List <[EMAIL > PROTECTED]> > > cc: (bcc: Patrick Reyes/CDS/CG/CAPITAL) > > Sent by: Subject: Re: Cache question > > [EMAIL PROTECTED] > > > > > > 06/03/2003 > > 11:38 AM > > Please respond > > to "OJB Users > > List" > > > > > > > > > > > > [EMAIL PROTECTED] wrote: > >>>3. you can use the PerBrokerCache so that changes to cached objects are >> >>only visible within one thread. >> >>I don't seem to be able to find PerBrokerCache. > > > See OJB.properties file: > #---------------------------------------------------------------------------------------- > > # Object cache > #---------------------------------------------------------------------------------------- > > # The ObjectCacheClass entry tells OJB which concrete instance Cache > # implementation is to be used. > #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl > #ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl > #ObjectCacheClass=org.apache.ojb.broker.cache.MetaObjectCacheJCSImpl > #ObjectCacheClass=org.apache.ojb.broker.cache.MetaObjectCachePerClassImpl > > >>What is the consequence of >>the cached objects being only visible within one thread ? > > > Other threads won't see uncommitted changes. thus dirty reads are avoided. > On the other hand commited changes are also not seen! > To avoid problems you should use Optimistic Locking (OL) to avoid write > conflicts. > Using refresh="true" will help to reduce OptimisticLock exceptions in > such a scenario. > > >>>By default OJB uses a global cache, so changes to any cached objects are >> >>visible across the whole JVM. >> >>What if I use the OJB in server mode with a multiuser environment ? > > > Then you should use > ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl > + OL. > And if you don't want to handle many OL exception you can set > refresh="true" for all persistent classes. > > cheers, > Thomas > > >>Regards, >> >>Patrick Reyes >> >> >> > > >> Thomas Mahler > > >> <[EMAIL PROTECTED] To: OJB Users List > > <[EMAIL PROTECTED]> > >> > cc: (bcc: Patrick > > Reyes/CDS/CG/CAPITAL) > >> Sent by: Subject: Re: Cache question > > >> [EMAIL PROTECTED] > > > > >> 06/03/2003 > > >> 10:51 AM > > >> Please respond > > >> to "OJB Users > > >> List" > > > > >> >> >> >>Hi Patrick, >> >>[EMAIL PROTECTED] wrote: >> >> >>>Hi guys, I am quite sure this is the right behavior of the cache, but I >>>would like some clarifications. >>> >>>1) I read the content of a table and store the corresponding objects in a >>>Collection. >>>2) I update the content of the objects. >>>3) I re-read the content of the table without updating the modified >> >>object. >> >> >>>4) Instead of replacing the content of the updated object with the >> >>content >> >> >>>stored in the database, the updated object is retrieved a such with its >>>modifications. >>> >>>My questions are: >>> >>>1) Is this due to the internal cache ? >> >> >>Exactly! If you perform any OJB query, OJB will first check if a result >>object is already cached. If so, the cached version is returned. >>(even when the cached object is dirty (i.e. contains uncommitted > > changes))! > >> >>>2) How can I ask OJB to retrieve only comitted changes from the database >> >>? >> >>1. you can call broker.clearCache() to empty the cache before performing >>a query. >>2. you can also set the class-descriptor attribute refresh="true" this >>will advise OJB to always load instances of a given class from the db >>and not from the cache. >>3. you can use the PerBrokerCache so that changes to cached objects are >>only visible within one thread. >> >> >> >>>3) If I use a muti-user environnment will each user get the same copy of >>>the object (i.e. the updated one) even if I have still not store the >> >>object >> >> >>>? >> >> >>By default OJB uses a global cache, so changes to any cached objects are >>visible across the whole JVM. >>You should use the PerBrokerCache in a multi user / multi thread >>environment to change this behaviour. See OJB.properties for details. >> >> >> >>>4) Does this behavior have anything to do with the optimistic caching ? >> >> >>You mean Optimistic Locking? Not really. It's just Global vs. Local > > cache. > >>cheers, >>Thomas >> >> >> >>>Thanks and regards, >>> >>>Patrick Reyes >>> >>> >>> >>>--------------------------------------------------------------------- >>>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] >> >> >> >> >> >> >>--------------------------------------------------------------------- >>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] > > > > > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
