Re: Caching problem

[Thomas Mahler]

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]>