[TransWarp] PEAK persistence requirements and implementation
roche at upfrontsystems.co.za
Fri Jun 28 14:05:32 EDT 2002
> CRITICAL: Clients of an Element should not be required to participate in
> persisting it.
This sounds great! From my understanding from the rest of your email
elements are persisted per attribute change if attribute changes are not
nested in operations.
> CRITICAL: "Intensional state". An Element should be able to refer to its
> state in terms of a key. If a cached Element refers to a state
> object that
> was cached across transactions, and the cached state has changed
> keys, the
> cached Element should not re-use the cached state.
I don't quite understand "and the cached state has changed keys". If an
element is cached by key how can this key ever change? Understanding
this also seems fundamental in understanding the last couple of paragraphs
in you proposal where you talk a lot about key changes.
> "State" objects, similar to TW's old Record objects, maintain a pair of
> mappings of field names to immutable atomic values (or tuples
> thereof). One mapping represents "persistent" state, i.e., what is
> currently in the underlying DB. The other represents "dirty" state, i.e.
> what has been written but not yet sent to the DB.
I find the name "State" very ambiguous, especially in a database context where
anything from transactions, records and the database itself are statefull.
It sounds like the mappings you mention above are really "Records" or maybe
"RecordSate" and that "State" is characteristic of a particular mapping.
When I re-read your mail with that in mind I understood a lot more.
> When a state object is looked up, the Element must check
> its own nesting count, and if positive, it should pass a "begin"
> message to
> the newly-retrieved state.
I don't understand this. I thought that calls to beginOp are explicitly
and optionally made by the Element - it sounds like something automatic is
Upfront Systems http://www.upfrontsystems.co.za
More information about the PEAK