Nicolai Krog wrote:

Hi Armin,

WOW, thanks! You were right; I changed the object-cache implementation to ObjectCachePerBrokerImpl (it was the ObjectCacheDefaultImpl before), and the problem vanished! :-D

This was REALLY nice of course, but the whole thing has made me sweat a bit; my application is quite sensible, - I simply cannot allow these dirty reads to happen! A 99% trust in ObjectCachePerBrokerImpl is not enough - I have to be sure!

For me the important question is now: "Can I now sleep calmly knowing that things like this will NEVER happen again?"


This should be 100% safe, because it's guaranteed that the cache was cleared on each PB.commit/abortTransaction and PB.close call and each thread use it's own PB instance (Disadvantageous will be the low hit rate of the cache).

An other thing: I have performed a lot of JUnit testing on my app, and in these tests, this error is not present. Do you have any thoughts upon why it is, that the error only happened when I tested through the web?


Did you use concurrency tests too? Maybe your problem only happens when concurrency access happens in your web-app

Also, I would like to know, if the ObjectCachePerBrokerImpl is very expensive in performance?


yep, much more than ObjectCacheDefaultImpl, because you will only get a hit when you obtain an object within the same PB instance again. But if your DB scales well, this shouldn't be a big problem.


In OJB it is possible to use caches per connection and/or per class. So you can use the default cache for classes which will not be updated to often and set a timeout for refresh. Additionally you can use the 'refresh' attribute in class-descriptor (loads data from DB for each lockup) or in reference-/collection-descriptor (loads the referenced objects again [from cache or DB]).
For classes you want to guaranteed avoid dirty-read you can use the ObjectCachePerBrokerImpl.


regards,
Armin

Thank you so much for your repsonse, - you made my day!

Kindest regards,

Nicolai


Armin Waibel <arminw <at> apache.org> writes:






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