[PEAK] The path of model and storage
Phillip J. Eby
pje at telecommunity.com
Wed Jul 28 15:24:07 EDT 2004
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
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
More information about the PEAK