[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]
