[ZODB-Dev] database conflict fail

[Claudiu Saftoiu]

>
> You shoudn't need to be building your own locking system on top of
> ZODB, this suggests that either ZODB is the wrong tool for your
> problem, or that you're using it wrong ;)
>
> ZODB has MVCC which means you get a consistent view of the database
> from the time the transaction was begun (see
> http://en.wikipedia.org/wiki/Snapshot_isolation.) In a web application
> using ZODB, each new request begins a transaction and at the end of
> the request the transaction is committed. If that commit raises a
> conflict error then the request is retried (usually up to three
> times.) Perhaps you could build on top of one of the existing
> frameworks that has this behaviour built in, e.g.
> http://pyramid.readthedocs.org/en/1.3-branch/tutorials/wiki/index.html


Aye that's the crux of it. If I allow the retries, my app gets too slow.
Instead of completing a request that takes 200ms, then retrying it after
a conflict happens and spending another 200ms on it, I'd rather wait
50ms until the previous transaction finishes, and then go ahead and
do the request, knowing no conflict will occur.

It's difficult to offer any useful advice without knowing what you are
> trying to achieve here. Certain data structures (mostly those in the
> BTrees package) have conflict resolution built in. For instance, you
> can concurrently modify multiple values in the dict like
> BTrees.OOBTree.OOBTree (or any of the other variants) so long as each
> concurrent transaction is modifying different keys.
>

I have begun using OOBTree instead of PersistentDicts, and they took
care of most of my conflict issues - namely, the ones where different
keys of the data structure (not related to each other) were being
updated. That was the majority of my problem, actually, and that's solved,
now.

The issue now is when the same key in the same data structure is being
updated from two different locations. I definitely want to keep the latest
update. It would also be acceptable to abort the earlier transaction in
favor of letting the later one take place. However, I don't want to do
both, have one fail, and re-do one (3 total). It's just too slow and I don't
see it as necessary.

Does that help any?

Thanks,
- Claudiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/zodb-dev/attachments/20120321/8a932abd/attachment.html>