[rucksack-devel] Et tu, prevalence?

[Nikodemus Siivola]

I've been trying to wrap my head around persitent object
identity in relation to parallelism and transactions.

Everywhere I look, I see endless pain for allowing references to
persistent objects outside transactions.

* Assume references to the same (EQ) persitent objects in two
  different transactions. Assume transactions update any instances
  referred to within their scope on first access. BANG -- the other
  transaction breaks as the object is EQ.

* Assume two P-EQL but not EQ persistent objects, X0 and X1. Assume
  transactions _don't_ update objects on first access. First a
  transaction sets a slot in X0 to a different (non P-EQL) object, and
  commits. Then another transaction starts, and reads the same slot
  from X1, which it didn't get from cache/disk, but through a reference
  held outside a transaction. BANG -- the value is not the same one
  committed, as the proxy in X1 points to wrong object-id.

Damned if you do, damned if you don't. Workarounds can be built
(instead of proxying the slot value proxy a cell that holds the value
to fix case 2, abort transaction in case 1) -- but I'm not sure the
pain is worth the gain.

I think these are symptoms of me trying to see two different things in
Rucksack as once -- (1) a solid transactional system suitable for
parallelism and distribution, and (2) a persistent lisp-heap.

I'd really like to have both. They match different needs, but
they also _have_ different needs.

Here's the idea:

Perhaps what is needed is prevalent-class/object in addition to
persistent-class/object? (Referring to "lightweight" in-memory
prevalence with write-ahead logging and recovery: it isn't as suitable
for server/client division or distribution like "proper persistence",
and isn't as good with parallelism... but you can hold on to
references outside transactions, and they are always EQ.)

I can certainly understand if this is deemed a bad idea / outside
the scope of Rucksack, but I for one would find such a pairing
natural along with providing a low-level serialization API.

What do you think?

(In any case, I've come to my senses and have no desire to hold
references to persistent-objects outside transactions anymore.)

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."