On Jan 9, 2004, at 8:05 PM, James Treleaven wrote:
> Hi Andrus,
>
> Thanks very much for your response.
>
> I really need to know two more things though:
> 1) Can I turn Level 1 caching off? I certainly hope so!
> 2) If I can - how do I do it?
Turning off Level 1 cache can mean different things. It is not all that
trivial. I don't know what exactly you are trying to achieve, so lets
look at what is cached at Level 1.
Most obvious thing is object properties. An object (or a relationship)
is fetched once, subsequent accesses to object simple or relational
properties do not trigger database operations, so technically object
data is "cached". E.g. "caching" of to-many relationships behaves like
that:
// returned list is not resolved yet
List paintings = artist.getPaintingArray();
// since this is the first attempt to read the list contents,
// it will trigger a DB fetch and populate the list
Painting p1 = (Painting)paintings.get(0);
// since the list is already resolved, p2 is returned from memory, not
// from DB... Technically this is "caching"
Painting p2 = (Painting)paintings.get(1);
Refreshing objects or lists on every "getXYZProperty" method call would
be wasteful. It is up to the developer to refresh objects when needed.
E.g. by executing a select query at the right moment (all returned
objects will be refreshed) or by invalidating individual object via
DataContext.invalidateObject(...). So developer would have to balance
between probability of stale data and app performance.
There is another case though where local caching may be more harmful -
when UPDATE queries are built they are compared with DB row snapshots
cached when they were last fetched. Since then an underlying DB row
could've been modified or deleted by another application or even
another DataContext in the same VM. This leads to race conditions if
two users or processes simultaneously update the same data.
There are a few possible solutions (aside from ignoring it :-)).
Notably "optimistic locking" - building an UPDATE query so that it
would detect changes to one or more "locked" columns, allowing an
application to throw an exception on commit or react in some other way.
Optimistic locking is planned for 1.1 (or maybe 1.2, whatever our final
release schedule becomes in the next month or so). Nobody started on
this yet, though some preliminary research has been done.
Second approach, kind of "optimistic locking light", is forced
refreshing of snapshots of all modified objects before commit. It does
not exist in Cayenne in a ready to use form, but can be implemented
using current API (and probably much easier - using new 1.1 ObjectStore
API).
Third approach would be using a DB-level lock on rows. We are not
implementing this at the moment, but this is possible to do.
As I said I don't fully understand what problem you are solving... The
solution might not necessarily be turning off the cache.
Andrus
This archive was generated by hypermail 2.0.0 : Fri Jan 09 2004 - 20:59:23 EST