> And this performance gains is only happening if one is trying to lookup via
> primary keys...
Not exactly true. The cache is also used during arbitrary queries. After a
SELECT statement is executed and before an object is built from a result set,
OJB first checks the cache to see if the object already exists. This provides a
performance gain by:
1. Not creating/garbage collecting another object in memory.
2. Not requiring additional queries if the cached object has already loaded
it's related objects.
> ...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.
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]
&msgId=445655 (<-- I don't think this issue has been fixed 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.
Cheers,
Richard
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
