Hello Jair,
Automatically clearing the cache for the object touched by the aborted transaction may cause loss of data, let's say it so, if storing data to db fails due to a temporary db failure, then you will loose all the data you last entered (if you don't have them backed up in other value objects). So I would say that always and uncoditionally clearing the cache is not a good idea. However it would be very useful if the PersistenceBroker would have a method that allows to get the list of all affected persistent objects and let the user decide if they have to be removed from cache (ev. directly with another method call).
Just to clarify: Removing an object from the cache does not delete the object in any way. It just removes a reference from a hash table so that looking up this object from the db again will get you a fresh, up-to-date instance. As long as you keep a reference to the modified object, you won't lose any data after clearing the cache.
yup, I know...
I probably didn't explain it well, let me explain better what I meant.
First the loss of data was not meant to be in the database, just the modifed data that should be persisted, would be lost.
(All the following bla bla make only sense if you are using OjbCacheDefaultImpl)
Little example: you have a web-application and want to update some user information. The user information entered by the user is put in a persistent 'UserInfo' instance. Now you try to persist it and BUM database is temporarly unreachable. The user should get an error page but should also get the entered values back.
If you just return the same unpersisted object, no problems, however if you get the data through a new OJB query, this may return the same object (if cache wasn't cleared) or a new object loaded from db (if cache was cleared) causing in this second case the loss of the user entered data.
That is what i meant. Now it is probably not a good practice in this example not to clear the cache and to send back the data to the user through a new OJB query, since this will cause a cache <-> database inconsistency. However this is a developer choice and may in some cases be of some use (have no idea in wich case, but who knows :) )
cheers danilo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
