Well, you know...
In this one project, we had an interesting (cough) situation with
PostgreSQL + psycopg, where we would see plenty of write conflict
errors coming from the DB connector.
Turned out PostgreSQL has kind of an optimistic transaction
control, where the DB server returns
Maciej Wisniowski wrote at 2005-8-5 23:37 +0200:
Do you see a reason why your requests modify Procedure instances?
I find this strange: I would expect that they are rarely modified
(just once to set them up).
It's possibly because of _connect method in DCOracle2 SP.py. It
assigns to self
[Maciej Wisniowski, wrestling with _p_resolveConflict]
Because of errors like:
ConflictError: database conflict error (oid 0x0299de, class
Products.DCOracle2.DA.Procedure, serial this txn started with
0x035f0726c7bfca88 2005-08-01 08:38:46.816215, serial currently
committed
Assignments to _v_ attributes (they are so called volatile
attributes) do not change the persistent state and cannot cause
conflicts.
There must be some other modification to the procedure objects.
I should have written:
It's possibly because of _connect method in DCOracle2 SP.py.
It
Offhand it looks OK to me, but I don't have any of the code you're
using.
I think that it's not my code problem but rather something with
DCOracle2 and to reproduce this error it is enough to call
any 'DCOracle2 StoredProcedure' object simultaneously
by a lot of users (50 is enough for my
[Tim Peters]
Offhand it looks OK to me, but I don't have any of the code you're
using.
[Maciej Wisniowski]
I think that it's not my code problem but rather something with
DCOracle2 and to reproduce this error it is enough to call
any 'DCOracle2 StoredProcedure' object simultaneously
by a
Not correct. _p_resolveConflict is used in Zope 2.8.x (and in Zope 3)
exactly the same way it was used in 2.7.x. If it's not working, there
may be a new bug in 2.8.x, but there's been report of that yet.
Because of errors like:
ConflictError: database conflict error (oid 0x0299de, class
That looks like a write conflict. MVCC helps to lower/eliminate the
rate of read conflicts.
One option to reduce the rate of this write conflict is to tune the
session machinery to suit.
For example use session-resolution-seconds of say 300 seconds.
Thanks!
I've changed
Maciej Wisniowski wrote at 2005-8-5 09:23 +0200:
...
li Module ZEO.ClientStorage, line 877, in _check_serials/li
/ulConflictError: database conflict error (oid 0x0299de, class
Products.DCOracle2.DA.Procedure, serial this txn started
with 0x035f181b76214155 2005-08-04 08:59:27.686696,
Do you see a reason why your requests modify Procedure instances?
I find this strange: I would expect that they are rarely modified
(just once to set them up).
It's possibly because of _connect method in DCOracle2 SP.py. It
assigns to self _v_proc, connection, and errors count.
Yes, it's a bit
[Maciej Wisniowski]
...
One more question - am I correct that _p_resolveConflict
is not used anymore in Zope 2.8.x?
Not correct. _p_resolveConflict is used in Zope 2.8.x (and in Zope 3)
exactly the same way it was used in 2.7.x. If it's not working, there
may be a new bug in 2.8.x, but
It might. ZEO adds network overhead to ZODB transactions,
which generally increases the likelihood of conflict errors.
I've created ZEO and executed the same test
with my application.
Tests were done with SQLRelay backend (DCOracle2 is
running now ;))
I have tested this with 50, 55, 60
I've lost context here... is this good or bad? ;-)
I'm keenly interested in your results, so
please let me know.
I've just send my results ;)
Good or bad... it depends. It's much better than
it was with Zope 2.8.0, it is better than with
Zope 2.7.2 but it is not perfect because
errors
On Wed, 2005-08-03 at 23:02 +0200, Maciej Wisniowski wrote:
Previously you've written that:
Zope 2.8.0 ships with a TemporaryStorage
implementation (used by sessions in the default
configuration) which does not implement MVCC.
The one in 2.8.1 (now in beta) and better will
implement
I'm keenly interested in your results,
so please let me know.
Hi!
We have just executed two tests of our
app on Zope 2.8.1b1 and the results are
good now.
1. Application with SQLRelay backend
connected to Oracle. Simulation of 50 users.
No internal server errors :)
2. Application with
On Tue, Aug 02, 2005 at 11:28:40AM +0200, Maciej Wisniowski wrote:
Previous installation with Zope 2.8 was
on ZEO, this one is standalone Zope 2.8.1.
I'm not sure if this matters.
It might. ZEO adds network overhead to ZODB transactions,
which generally increases the likelihood of conflict
Hi!
Does anybody tried 2.8 and can say something about conflict errors?
I've done few tests and results are not good.
We've checked one of our applications on Zope 2.7.2 and the same
application on Zope 2.8. We have simulated 50-65 users executing the
same path in application. There was total
Hi Maciej,
I can't speak to the 500 errors you're receiving but Zope 2.8.0 ships
with a TemporaryStorage implementation (used by sessions in the
default configuration) which does not implement MVCC. The one in 2.8.1
(now in beta) and better will implement MVCC, so you *should* see
performance
Maciej Wisniowski wrote at 2005-8-1 12:21 +0200:
...
Other errors are like Shouldn't load state xxx when
connection is closed but these are known bugs in older ZODB version.
Really?
I do not know such errors in any ZODB version.
I know these errors as persistency bugs in applications (among
Other errors are like Shouldn't load state xxx when
connection is closed but these are known bugs in older ZODB version.
Really?
I do not know such errors in any ZODB version.
I know these errors as persistency bugs in applications (among
others some of mine)...
I've found this
I can't speak to the 500 errors you're receiving but Zope 2.8.0
500 is HTTP code, not the error count. I've written this in a
messy way.
Zope 2.8.0 ships
with a TemporaryStorage implementation (used by sessions in the
default configuration) which does not implement MVCC. The one in 2.8.1
21 matches
Mail list logo
