RE: Ref-counting for pristine texts

On Wed, 2011-01-26, Bert Huijben wrote:
> > -----Original Message-----
> > From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> >
> > Can anyone help me work out the rules for guaranteeing consistency of
> > the pristine text store?
>
> Previously we used a somewhat reversed definition: as long as there
> are work queue items or working-copy locks, you can't assume pristines
> are unreferenced.

Ah, WC-locks. Yes, that sounds more likely. (I don't recall that we
have ever used that rule yet. The pristine cleanup code has only ever
checked "WQ is empty", which isn't good enough.)

> Note that there can be multiple clients accessing/modifying a working
> copy at the same time even though they don't have a sqlite transaction
> open. (An update doesn’t keep it's transaction open for the entire
> update process).

Yes. Nor does the update process keep work items items in the WQ during
the whole time - it runs the WQ at various points. But there is a WC
lock through the whole update process.

So we can write a rule:

  "You may purge unreferenced pristines only when
   there are no WC locks in the DB."

More precisely, the access control rules for the pristine store in a
given WC shall be:

  * A process may add a new (initially unreferenced) pristine text
    to the store
    IFF this process has a WC lock.

  * A process may add or remove references to any pristine text that
    is in the store
    IFF this process has a WC lock.

  * A process that has a WC lock may assume that no pristine text,
    even if unreferenced, will be deleted from the store as long as
    this process holds any WC lock in this WC.

  * A process may purge an unreferenced pristine text
    IFF no other process has a WC lock.
    ### Must this process have a WC lock?

(I use the word "process" loosely.)

Does that make sense?

- Julian
Received on 2011-01-27 18:06:30 CET