Tim Peters wrote at 2003-9-14 16:40 -0400:
...
[Dieter Maurer]
Whoever wants to use it right now: the no more ReadConflictErrors
patch on
http://www.dieter.handshake.de/pyprojects/zope
does precisely this (for storages that support history information).
How has that
Tim Peters wrote:
Probably none for many apps. You'll be working with possibly non-current
data, so think of ways your apps could possibly be damaged by that. For
example, you're Bill Gates, using ZODB to track all your assets. A summary
report takes hours to generate, and by the time you get
[Tim]
...
The ways in which MVCC loses will become obvious later 0.9 wink.
[Chris Withers]
Any ideas what they'll be yet?
Probably none for many apps. You'll be working with possibly non-current
data, so think of ways your apps could possibly be damaged by that. For
example, you're Bill
[Tim]
...
The short course in ZODB is that, when MVCC is in effect, a
read will return the state of the object as of the time the current
transaction began, even if the object has subsequently been
modified by some other transaction.
[Dieter Maurer]
Whoever wants to use it right now: the no
Tim Peters wrote at 2003-9-11 23:50 -0400:
...
You can google on the phrase to get a ton of more-or-less abstract overviews
of the concept. The short course in ZODB is that, when MVCC is in effect, a
read will return the state of the object as of the time the current
transaction began,
Tim Peters wrote:
Multiversion concurrency control (MVCC for short) is the next step. If no
other crises intervene, Jeremy and I will start implementing that on the
ZODB3 3.2 branch (most likely that branch -- can't swear to it) soon
(ditto).
From Jeremy's recent notes, I think it'll be the Zope
On Fri, 2003-09-12 at 07:34, Chris Withers wrote:
Tim Peters wrote:
Multiversion concurrency control (MVCC for short) is the next step. If no
other crises intervene, Jeremy and I will start implementing that on the
ZODB3 3.2 branch (most likely that branch -- can't swear to it) soon
[Toby Dickenson]
You get a ReadConflictError when loading an object if it has been
modified since the start of the transaction. This exception
therefore becomes increasingly likely as time progresses since the
start of the transaction.
[Chris Withers]
What's the thing Zope Corp are touting
On Wednesday 03 September 2003 12:15, Chris Withers wrote:
If the object load would cause the cache to go above it's maximum number,
*Number* isnt the the right parameter to control here. We need to limit
the total amount of RAM. Objects are of variable size, and the largest ZODB
objects
Toby Dickenson wrote:
On Wednesday 03 September 2003 12:15, Chris Withers wrote:
If the object load would cause the cache to go above it's maximum number,
*Number* isnt the the right parameter to control here. We need to limit
the total amount of RAM. Objects are of variable size, and the
On Friday 05 September 2003 14:21, Chris Withers wrote:
Hmmm, maybe not... could we make a note of the pickles size when the data
is loaded and update that size when it's comitted? Is this the same as the
in-memory size?
Yes, I hope its close enough for most purposes. It would be nice to have
Leonardo Rochael Almeida wrote:
as a lower bound. (Note that the cache is still allowed to grow
indefinitely within the scope of a request, however.)
This is the single biggest cause of Zope becoming unresponsive for me:
people doing silly things that drag hordes of objects into memory i na
Shane Hathaway wrote:
as a lower bound. (Note that the cache is still allowed to grow
indefinitely within the scope of a request, however.)
Which is still pretty broken IMHO :-(
This is the single biggest cause of Zope becoming unresponsive for me:
people doing silly things that drag hordes of
On Fri, 2003-08-29 at 06:28, Chris Withers wrote:
Shane Hathaway wrote:
as a lower bound. (Note that the cache is still allowed to grow
indefinitely within the scope of a request, however.)
Which is still pretty broken IMHO :-(
This is the single biggest cause of Zope becoming
14 matches
Mail list logo
