[Zope3-dev] Re: [ZODB-Dev] ZODB4 project plan

[Toby Dickenson]

On Wednesday 27 November 2002 2:55 pm, Shane Hathaway wrote:

> One solution is to use an application-level lock that only gets acquire=
d
> for long-running transactions.  Before making changes, the catalog is
> expected to check whether this lock is set.  If it is set, it should
> kindly put items in the queue instead of changing the catalog.

Or you could have one queue per long running transaction. All long runnin=
g=20
transactions write their changes into their queue.

Outside all long running transaction, all you would see is a pool of empt=
y=20
queues. That remains true until a long running transaction commits, and o=
ne=20
queue is filled. Some short-running transaction merges the queue.

>  If the
> problem is solved that way, version locks don't seem to help any.  Or d=
o
> they?

Yes. Not all operations will use the queue. Even if we queue most catalog=
=20
updates, we might not want to bother implementing a queue the creation of=
 a=20
whole new index. Without version locks, *every* object would need to prov=
ide=20
a queue (or lock) for every operation.