Hi I just want a few precisions about this mail. Can you explain the fact that ODMG API removes object from the cache at transaction commit, because I'm facing the same problem and I can't explain to myself this fact, or if it is hard to explain can u throw some resources or links
Thx in advance Le sam 04/01/2003 � 10:29, Thomas Mahler a �crit : > 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]> -- Kevin Viet <[EMAIL PROTECTED]> ActiVia Networks -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
