Re: Using substanced with Zeo and keep getting database conflict errors

> On Sep 14, 2016, at 01:30, Jo Gilder <[email protected]> wrote:
> 
> At what level is the zodb locked for editing by a transaction? Is it at the top level of a node? Is it from the edited object and then anything referenced by it or anything below it in the tree?

ZODB uses an optimistic concurrency model, which means it doesn't employ locking for editing. Editing is allowed to proceed in parallel by many connections. Only when it comes time to commit does a winner have to be picked. The first connection to commit a concurrently edited object wins; the other connections either have to resolve the conflict or they raise ConflictError. 

Now, the process of picking a winner and then resolving conflicts is serial, so that implies locking of some sort at commit time; ZEO and RelStorage lock the entire database, but other storages (NEO) use finer-grained locks. However, the effect---edits to particular objects are sequential---is the same.


> As the data import is a one off process then this may not be an issue. What would be an issue is if two users of the web interface aren't able to edit parts of the same tree. I can understand they couldn't both edit the same object but what are the limits?

Basically that's application-specific. It depends on conflict resolution and retry logic, and what objects are contended for writing beyond the user-visible object (someone mentioned indexes as a non-direct type of object that can be affected by editing---depending on the application).

(To an extent it's a ZODB storage issue, too, but only in the sense that some storages may be able to perform commits faster than others for certain workloads, thus enabling a higher transaction throughput. But that's not really what we're talking about here.)

> Would it make a difference if I used relStorage instead of zeo?

Since this seems to be an application level issue, probably not. Both storages do the same basic job, just with different tradeoffs. You *might* find that the timing of operations is perturbed just enough by switching storages that you don't see this issue, but that doesn't mean that the issue is fixed, it's still lurking and can crop up again. On the other hand, you may find that the timing is perturbed such that you see *more* conflicts. Again, it's probably an application issue.

Jason

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.