> > ...but a single cache does not prevent my application threads messing up > > each others work (actually it will happen at some point!) > > Threads will not mess up each other's work if you: > 1. Read/write lock your objects in the context of an ODMG transaction. > and > 2. If reads/writes are done outside the context of an ODMG transaction, ensure > that any thread only modifies a private copy of an object (e.g., via > serialization or cloning) > and > 3. Utilize optimistic locking.
Optimistic locking does not help if two threads get the same two objects with a read lock and then the first thread tries to upgrade it to a write lock (which it will get as Thread 2 only have a read lock)... Then tread 1 commits its stuff., the objects ids gets updated....something bads happen and the transaction rollsback.... Voila - thread 2 now holds a reference to an object which it has only read and the values for it are STALE is it not ? The optimistic lock ids have been incremented, some values inside it might have changed....how can this be avoided even with 1 or 2 and 3 fullfilled ? > and > 4. To avoid certain race conditions, apply modifications to your persistent > objects and OJB source-code as explained in this previous e-mail: > http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] .org > &msgId=445655 (<-- I don't think this issue has been fixed yet...) As I understand point 4 it is a requirement that the objects implement StateAware - and this should not be necessary! At least I for one wish the objects being stored/returned are standard naive java objects. And the changes explained in nr. 4 is not in the OJB cvs (is it ?), so it is not a solution (yet!) > > I'd be interested in seeing anybody's test-case that demonstrates data-integrity > problems while following the above guidelines. From my experience, if you follow > them you can safely utilize a single, global cache in OJB and thus realize > significant performance gains. Doesn't my example above demonstrate this ? And btw. All of the above guidelines would not be required if each persistencebroker/transaction had its own cache! One could survive with optimistic locking if one could live with a possible failure on commit. And this could be avoided if one uses read/write locks - all without ever having to think about two threads stepping on each toes, because they CAN'T when there are separate cache. (errata: They actually can step on each of their toes, but they have to do it explitly opposite to the current solution where it can happen by chance/implicit) Im I making any sense ? /max -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
