RE: [OJB-developers] Single VM Object Cache Consistency?

[John F. <jfr...@so...>]

Hi Thomas,

> The original intention of a cache was not primarily to boost=20
> performance but to maintain uniqueness of persistent Objects accross a
VM.
> But without tx isolation on the PB level this is dangerous as your
> example shows. Maybe we need a redesign of this aspect. There are
similar thoughts in
> the JDO spec. They only provide uniqueness of objects within one
> transaction.
>=20
> having transaction local caches would be the most simple solution and
> simplify a lot of things (e.g. cache synchronization).


I'm working on trying to change things so that

a) Each PB has its own private object cache which is transactionally
consistent (the cache is flushed on each commit/abort tx.  This behavior
is controlled via OJB.properties.

b) Classes can be marked for "VM wide" caching (multiple PBs will share
these objects).  These classes must be thread safe and used to hold
"read only" data from the database.  This cache is not flushed
automatically when tx's commit/abort.

I've got it coded and I'm testing it out more today.  It is mostly a new
cache implementation class - the impact on the rest of the code is
actually pretty minimal (and this new behavior can be turned on/off
easily).

However, your comment about the cache providing "uniqueness of
persistent Objects across a VM" concerns me.  Clearly with PB local
caches, you can have multiple object instances in the VM that have
identical database identity.  From what I can tell, I don't see this as
a problem, but with your greater experience do you see any problems with
the above approach?  Would this play havoc with the higher layers that
I'm not familiar with (odmg or the planned jdo)?

Regards,
 - John