Durus has no way of knowing if you want your client to retry
or do something else when there is a conflict.  A conflict isn't
just a lock:  it means you are attempting to commit a change
based on out-of-date information.   Wrapping every writing
function with this logic won't fit every case.  In the case of
a web server, I'd suggest having only one retry loop like
this around the function that does all of the request
processing.

The altdemo.py should include something like this retry logic,
but making it work well with sessions and such can be tricky.
That is precisely why the QP package was written, and
you might want to take a look at it.

If the application is designed correctly, there should not be many retries.
The conflicts occur when multiple durus clients are writing
at close to the same time to the same persistent instances.
The altdemo.py is not designed to avoid conflicts.
Among other things, it writes to the session
instance on every request.  If you have multiple clients handling
rapid bursts of requests from the same client, this will tend to
cause conflicts.


On Aug 26, 2010, at 2:42 PM, Salman Haq wrote:

> Thanks Gabor! That works.
>
> Neither the Durus README file nor the online FAQs mention anything about re-
try logic.
>
> Salman
>