Hi again,

[EMAIL PROTECTED] wrote:
Thanks for your answers Thomas, great reply as usual!

Now I have another question. Is having a global cash not quite dangerous in
a multiuser environnment ?

Sure! That's why it's not recommended!


I.E. A different user might change an object that is not comitted, what if
the originator doesn't commit the original changes later ?

This could be avoided by turning on Optimistic locking. But still having all those dirty reads is no fun in a multiuser environment.


When using the cache, when shoud I commit the cache information to the
database ?

Depends on your application. Usually it's the best thing to keep broker transactions open as short as possible.


I suppose if OBJ dies, the changes are lost, on the other side
it is quite more efficient to use cache and not save each time to the
database, what is the best way of handing this in a multiuser environnment
?

You should use the PerBroker Cache in a Multiuser environment. For each User session use a dedicated broker with it's own local cache. SO changes of a user are not visible globally, but only within this users session. Of course you should also use Optimistic Locking to avoid write conflicts in such a scenario.


Thomas

Thanks and 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]



Reply via email to