On Jun 5, 2006, at 9:09 PM, Jesus Cea wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Looking for ways to improve my BerkeleyDB storage backend for
> durus, my
> current concern is about "object resurrection" and things like that.
> Thinking about this, I remembered the "sync" method in the storage
> interface. This method seems to be useful to notify the connection
> using
> the storage (a fileconnection or a storage server, usually) about OIDs
> that must be "ghosted" because the background work of the storage
> backend itself (in my case, the background garbage collection).
>
> But this possibility seems not to be actually used by current Durus
> code. If fact, seems explicitelly unusable. For example, the sync
> method
> is not called in the "commit" management in the storage server, and
> the
> explicit "sync" message in the storage server denies usage of this
> aparently useful feature with an assert:
>
> """
>         invalid = self.storage.sync()
>         assert not invalid # should have exclusive access
> """
>
> Arggg!.

In a normal Durus application, where the StorageServer's purpose is
to make a FileStorage available to others, the underlying storage
should never have any invalidations to distribute.

Your storage is too smart for this StorageServer.

Deleted objects are not the same as invalid objects.  I don't think
it is the right choice to report them back in the same group.

>
> Warning: 3:15AM in the morning in Spain, so I could missunderstand the
> durus code.
>
> PS: This is not Durus 3.5 release material :-p.
>
> PPS: About Object Resurrection: Suppose a persistent object tree.
> Suppone now that we keep a non persistent referente to some branch and
> severe the persistent link. Suppose garbage collection kicks in. Now
> that branch could be deleted in the storage, since no persistent link
> links it to the main tree. But since we still keep a nonpersistent
> link
> to the branch, the objects in the branch are active and well sitting
> idly in RAM :-). Yes I know I *SHOULD NOT* keep nonpersistent
> references
> across commits; I'm just doing my best to detect such a situation
> in my
> storage backend.

The Durus StorageServer is not made for untrusted, badly behaved
clients.
That helps it to be reasonably simple.  This is not the only way that a
hostile client could damage your stored data.  It could, for example,
commit a reference to a Persistent instance that has never existed in
the
database at all.

>
> My idea would be to publish invalidations to ALL objects garbage
> collected, to force them to ghost state (so, if your code touch them,
> you will get a conflict, as should be) and all commits should be
> able to
> raise "post conflicts" if a commited object has any link to a
> nonexistent object.

We could do this, but it would be complicated, and I think it would have
no advantage at all for clients that do not hold and misuse references
to transient objects across packs.