On Thu, Jul 15, 2004 at 06:09:29PM -0400, Jim Fulton wrote:
Locks are important, however, in cases such as generating unique IDs
based on integer attributes in a database.
I don't know what this is.
Well, let's say I wanted to have a unique ID for payments (people want
to refer to them for
Jim Fulton wrote at 2004-7-15 17:18 -0400:
Dieter Maurer wrote:
I don't think anyone find versions useful in cases where
locks matter. With versions, if you get resource contention,
someone loses.
Yes, but hopefully the short running (inexpensive) and not the long running
(expensive) process...
Christian Robottom Reis wrote at 2004-7-16 10:27 -0300:
...
The database itself uses a short-lived lock to generate oids.
Functionality which would be interesting if it were publically available
to solve the aforementioned problem.
The functionality to get OIDs is there.
It is the new_oid
On Fri, Jul 16, 2004 at 07:50:48PM +0200, Dieter Maurer wrote:
Christian Robottom Reis wrote at 2004-7-16 10:27 -0300:
...
The database itself uses a short-lived lock to generate oids.
Functionality which would be interesting if it were publically available
to solve the aforementioned
On Fri, Jul 16, 2004 at 08:39:52PM +0200, Dieter Maurer wrote:
In either case, if you have
resource contention, you are probably out of luck.
Luck is not a binary concept ;-)
Our current most essential use case for Versions is reindexing
large catalogs. Reindexing can take hours. It is
Jim Fulton wrote at 2004-7-15 10:00 -0400:
...
Given this, I'd like to formally announce the intention to deprecate
versions in both Zope and ZODB. We will formally deprecate versions when
we have a way to maintain long-running transactions in Zope. I have a good
idea how they would work and
On Thu, Jul 15, 2004 at 05:18:37PM -0400, Jim Fulton wrote:
I don't think anyone find versions useful in cases where
locks matter. With versions, if you get resource contention,
someone loses.
Long-running subtransactions as I'm proposing would rely on mult-version
concurrency control,
