[PEAK] The path of model and storage

[Phillip J. Eby]

At 01:59 PM 7/28/04 -0500, John D. Heintz wrote:

>Phillip: are you answering that each thread in PEAK has it's own proxies 
>to data objects?

More or less.  I'm saying that if you want threads to access the same 
in-database objects, then you should do so via a thread-specific 
workspace.  A workspace provides you with a proxy that represents the 
in-database object.  You can never directly access the object in the 
database directly, as that's what the workspace is supposed to mediate for you.

(The difference between my answer and your proposed answer is that your 
phrasing implies that the per-threadness is automatic, when in fact you 
must explicitly create and manage workspaces (and indeed complete component 
hierarchies) for each thread.)


>Hibernate (an object-relational bridge layer) supports two levels of 
>caching: Session and clustered. See http://hibernate.org/21.html#A43
>
>I suspect that Robert is interested in the same thing I am:
>What is the PEAK-ish way of layering data caching into a process and 
>across processes?

In-process is handled by the DM (today) and workspace (future).

Across-process caching you'll have to develop yourself, according to 
need.  Presumably, you'll do this by implementing a workspace (or a mapping 
facility to use in one) that accesses your desired cross-process cache.

It's somewhat more likely that PEAK will offer workspace hooks for remote 
cache invalidation, to let workspaces in other threads or processes know 
that their cache may be stale.  I think this is more likely to be useful 
than trying to duplicate the DB tier's caching facilities in a 
cross-process cache.