durusmail: durus-users: Re: sync
Re: [Quixote-users] newbie mod_python+quixote+dojo
Re: [Quixote-users] newbie mod_python+quixote+dojo
2006-10-21
Mike Orr
2006-10-22
Oleg Broytmann
Fwd: [Quixote-users] newbie mod_python+quixote+dojo
2006-10-22
Mike Orr
2006-10-23
Jesus Cea
Durus future (Was: Re: [Durus-users] Re: [Quixote-users] newbie mod_python+quixote+dojo)
2006-10-23
Jesus Cea
Re: sync
2006-10-24
David Binger
2006-10-24
Jesus Cea
Re: sync
Jesus Cea
2006-10-24
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Binger wrote:
>> David, please, implement "sync" :-)
>
> By that, do you mean, that the StorageServer
> calls self.storage.sync() with the expectation
> of getting a list of invalidations that should be
> passed along to all clients, and that this storage sync
> should also be called at the top of the commit() handler
> method and upon the completion of a pack?

Basically yes: anytime the client ask for an invalidation list, the
storage server should ask for invalidation updates to the backend.

Currently Durus only source of invalidations are commits from other
clients. Let's add to it invalidations from the storage.

I would not touch "pack", nevertheless. The objects invalidated in a
pack (garbage collected) will be known when a client do a commit/abort
and the server asks for invalidations to the storage backend. I see
"pack" as an implementation artifact.

I would ask also for sync implementation in the FileStorage, to be able
to share a single "proxied/wrapped" filestorage between multiple
connections inside a single process, for example.

Aditionally (maybe not until Durus 3.7), would be nice if a commit could
fails also after the client send its changed objects, to improve
concurrency when an application has many write transactions to disjoin
objects.

For example, a single durus server process could have a "thread" server
per client (to be able to serve multiple read request in parallel, for
example), all sharing a single backend. Multiple write commits could be
able to proceed in parallel if they don't share any object.

The posibilities are endless, without touching any additional durus
code: replication, caching, load sharing, etc., all implemented in the
backend, not in durus.

PS: Probably the clean way to do this would be to drop current
invalidation code and let the backend propagate them. That is, when
doing a backend commit, return two invalidation lists: one for the
client doing the commit (probably empty) and one to propagate to any
other client (taht includes all objects changed by the commiting
client). The backend must be upgraded, so current ones would be
incompatible. As ever, I'm ready to upgrade my backend to cope with this
feature.

PPS: Current backends could be done compatible with a trivial "wrapper".
That wrapping could be automatic when instancing a connection, simply
checking for an appropiate interface in the connection "__init__()"
method, probably with an appropiate "deprecation" warning.

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

iQCVAwUBRT38+Jlgi5GaxT1NAQIyAQP/WlvfjtObGkOpgvF4ZTiaVKNOQCqPxSXS
+n6gyITzWnr2nLeSYud1W6wMQmp1UoukMPG/khbk5VD4EZTS0rTCbUmaswtp+FG3
xEVqZG+7FlzPwtF3XwYr4pNX3zmhqr3HEEcKZ/p36dw4T/9UsbF+kYihLhAvWDD7
fIioWc1d3qg=
=0mGF
-----END PGP SIGNATURE-----
reply