Hi again David, [EMAIL PROTECTED] wrote:
If you are aware it is OK. But if for some reason a GC is called within your tests you might get test failures...1) I am aware of the dangers of ==, but it's the easiest way to test if something comes out of the cache that I know of (in a simple test environment, I find it reliable).
OTM = Object Transaction Manager2) What is OTM?
OTM is intended as a layer where things that ODMG and JDO have in common are abstracted.
One of these shared things is transactional cache management.
Work on OTM is quite progressed. As a next step we will reimplement the ODMG implementation on top of the OTM layer.
finally we will build a cleanroom JDO implementation on top of OTM.
(see also: http://jakarta.apache.org/ojb/jdo-proposal.html)
3) I'll see what I can do about a patch...
thanks! Thomas
|---------+---------------------------> | | Thomas Mahler | | | <[EMAIL PROTECTED]| | | > | | | | | | 01/04/2003 04:29| | | AM | | | Please respond | | | to "OJB Users | | | List" | | | | |---------+---------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: OJB Users List <[EMAIL PROTECTED]> | | cc: | | Subject: Re: Caching problem | | | >--------------------------------------------------------------------------------------------------------------------------------------------------| Hi David, [EMAIL PROTECTED] wrote: > Here is my problem. I have the following model (0.9.8, single VM) > > A contains a B. > > I have the following data. > > A1 containing B3 and A2 containing B3 > > A1 and A2 are loaded (so they should be in the cache) B3 shoud also > be in the cache. > > I update A1. > > I load A1 and A2. > > At this point, it appears that: A2 came from the cache A1 did not > come from the cache. The B pointed to by A1 and A2 are no longer the > same B (== fails, to put it in Java terms) > Even if your app is not running as an ODMG app, it is not generally safe to check for == ! The cache could also be cleared ba a garbage collection and thus could enforce reloading. > It appears that updating A1 has flushed A1 and B3 from the cache? > > > Is this correct behavior? > Currently the ODMG API removes all objects locked to a tx from the cache on commit(). This is done to preserve proper tx isolation. > > ObjectEnvelopeTable.commit() contains the following.... command line > of code... // in a distributed environment all broker caches must > invalidate the Object broker.invalidate(new Identity(mod.getObject(), > transaction.getBroker())); > > However, it appears that the singlevm is flushing the object from the > cache also. Correct! There had been long discussion on transactional isolation with ODMG and I wanted to be on the safe side! The new OTM layer will provide a more intelligent cache management. > Personnally, I would really rather not have objects removed from the > cache just because I update them. > I agree, this does make no much sense in singlevm mode! If you are preparing a fix I will commit it to CVS ! cheers, Thomas > This is causing me a problem, because I go and load "bunches of A's", > and some come from the cache, and some do not, which means the B's > are "who knows what", and I'm trying to build a "complex" internal > data structure, but when B is inconsistent, thinks don't work well. > > Thanks David Corbin > > > This message contains information from Equifax Inc. which may be > confidential and privileged. If you are not an intended recipient, > please refrain from any disclosure, copying, distribution or use of > this information and note that such actions are prohibited. If you > have received this transmission in error, please notify by e-mail > [EMAIL PROTECTED] > > > > -- To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> For additional > commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
