On Apr 22, 2006, at 8:05 PM, Jesus Cea wrote:

> As ever before, the problem is different environments :-). Durus is
> clearly designed for mostly read applications. For example, a forum
> server, or nearly static webserver. I'm using it out of design
> parameters, for "a lot of writes" applications. For example, my
> mailbox
> storage server (about 50% read and writes) or my GIS application
> (about
> 5-15% writes). In fact I have some applications were read are minimal,
> and writes are very high. For example, statistics collection
> servers, a
> linda blackboard server, checkpointing services, etc.
>
> I'm fighting because I deeply feel that durus can be used
> efficiently in
> that environment, without applications doing workarounds to avoid
> false
> conflicts, durus server keeping a huge changeset per client
> connection,
> or read clients waiting (unnecessarily) for other read clients. I feel
> that those changes are simple enough, and useful enough for other
> users
> to benefice of them.
>
> I would like durus to be *THE* persistence server in Python world.
>
> Seems that work wouldn't be useful for mems-exchange. That's fine.
> Just
> let me to try :)

You don't need my permission.  I know we have similar interests,
and I'm glad you are thinking about this stuff.

I bet that the problem of false conflicts can be addressed without
complicating the state logic of persistence or hurting the performance
of read-dominated applications like mine.

Here is a thought.  Suppose you defined, very carefully, a subclass of
Persistent that, in addition to doing exactly what Persistent does, also
overrides attribute access and setting to put the oid into a set on the
Connection.    You would also use a careful subclass of Connection
that clears this set on every commit() or abort(), and uses it to
avoid certain conflict errors.

>
>> If my memory is right, our applications often get attributes many
>> tens
>> of thousands of times for a single page.  Keeping attribute access
>> time as low as possible makes every page faster, and the cost
>> of conflicts, especially false ones, is kept lower.
>
> Are you touching thousand of objects per page?. Or thousand of
> attributes of "few" objects?. My proposal only penalize the first
> attribute access to each object, not all accesses.

Thousands of objects.