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).
2) What is OTM?
3) I'll see what I can do about a patch...
|---------+--------------------------->
| | 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]>
