----- Original Message ----- From: "max" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Thursday, September 12, 2002 2:16 PM Subject: Re: Thought experiment...
> > > ...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 ? See the e-mail I just sent: http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] e.org&msgNo=2462. > > > 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. Yes. This is the ideal. Unfortunately, though, if you want to maintain data integrity in the current version of OJB you need to handle some things yourself. In my experience, objects (or the client application of OJB) can't be naive. In particular they have to be aware of their own 'new' state and they have to handle their own rollbacks. To all users: Does anyone on this list truly utilize naive persistent objects and yet use OJB's single, global cache? Maybe if you just disable the cache you can avoid these issues, but what about your performance...? > And the changes explained in nr. 4 is not in the OJB cvs (is it ?), so it is > not a solution (yet!) It is not in the CVS but I can certainly send out an implementation it you like. > > > > > > 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 ? Yes. Again, see my previous e-mail referenced above... > And btw. All of the above guidelines would not be required if each > persistencebroker/transaction had its own cache! Not true. You could still have the race condition explained in guideline #4 even with local caches. This problem is independent of any caching strategy. The point of this guideline is that you can't trust the state of the database to determine if an object is new (as OJB currently works). Your object needs to hold this 'new' state internally... (Does anyone have a different fix for this problem explained by Georg Schneider in http://archives.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED] .org&msgNo=1382 ?) Also, I don't see how you can get past guideline #1 and #2 AND have reasonable performance. Even if you have local transaction caches, you still need to read/write lock shared persistent objects (guideline #1) and, outside of a transaction, you still need to modify private copies of persistent objects(guideline #2). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
