-----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!.

Also, the "handle_invalidations" semantic in the storage "end" method is
not very clear to me, and seems that implementation logic is not
consistently implemented along durus code.

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.

Supose now that we relinks the branch, creating a persistent link using
the non-persistent link. We commits.

Now we have a dangling persistent reference, since the new pointer
points to objects not present in the storage.

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.

The first functionality could be done with a "sync" method, and the
second one, via the "handle_invalidations" in the "end" method. If Durus
could manage them consistently :-).

Thanks for your time.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea@jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRITV3plgi5GaxT1NAQJ+GQP+P8NH1Ad+avuujsO7+UX2cHnfpoNrDbJ+
UHjf0fbaXIcoNh+tesuTllri9B9H8TAOp6div0Qb1GEEFMxSXT62ZiD+TpOTk3Zi
AiilRqdt9wWMmkCY7iFdDsg2SYKTvd7ygMgRg4k0+5i+NnUve3Pw9zUM8JrBSGl0
o5bMW4KoffE=
=5hJQ
-----END PGP SIGNATURE-----