On May 17, 2006, at 8:35 AM, Jesus Cea wrote:
>
> You assume that clients are long running applications.

Yes I do.

> My antispam
> filter exports a durus server interface for other applications to
> query
> about statistics, updating whitelisting, etc. Such applications
> executes
> for half a second and could commit a couple of objects only, if any.
>
> Or my mailbox storage server, the LMTP server creates a new connection
> to durus per email to store, no reuse. Idem the POP3 server.

In Durus, as you know, all transactions are pushed through the
single storage server to make sure they can be serialized.
Do your applications really require global serialization?

> But the OID pool when a commit conflicts is useful to avoid latency
> issues when you redo the transaction, since those OIDs are already
> reserved to you, just reuse them instead of request new ones to the
> server.
>
> Implementation would be trivial: When a commit conflicts, now durus
> review the newly created objects and deletes the connection and oid
> attribute. I propose to store the deleted oids in a private list. When
> time later you do a new commit, just use the OIDs in that list, if
> available. If not OID available, ask for one to the server, just
> like now.

When you redo a transaction, you must call abort() before trying again.
You should just make the new objects again, if the invalidations have
not
changed your objective.  Sneaking them into the next transaction is
dangerous.

You could, however, keep track of the oids consumed during the
serialization,
and, in the case of a conflict, these oids could be restored to the
clients
pool of allocated oids.

>
> Probably less than eight lines of code :-p
>
>> You still haven't said why you want your storage server 50ms away
>> from you clients.  I know there must be a reason.
>
> Currently I'm using durus in USA<->Europe links to store statistics
> and
> logs and for things like configuration files. That is, daemons instead
> of reading configuration files from local disk, read the configuration
> from a durus object.

It seems like your applications are network file systems, except
that the file system has no directories and only a very particular
type of file.

>
> Yes, I've modified servers like squid, apache or sendmail to
> integrate a
> python interpreter and a "call to python" patches spread in the
> code to
> read configuration files or write logs to durus objects. Easier to do
> than to explain :-)