[Zope] Strangeness with Zope and Postgres

[Christian Theune]

Hi.

We had this problem too. The thing is with PoPy.
I think this is solved in a newer version of PoPy.

Please mail me again if a newer version won't help,
then i have to take a look how we solved this,
but we did, so go on and ask me.

Christian

On Thu, Nov 01, 2001 at 04:43:10PM -0500, Chris Kratz wrote:
> For months now, we have been noticing that every once in awhile zope just
> appears to freeze up.  I go and look at the zope processes and they are a=
ll
> sleeping.  The only way to fix the problem was to restart zope, hence I
> didn't think about the fact that it might be the database.  I have been
> monitoring it and assumed it was something funny in Zope, but something t=
hat
> was mentioned on this list made me start thinking that it could be someth=
ing
> funny happening with the database.
>=20
> We use postgres as our dbms and our site is heavily database instensive.
> Sure enough, when ever the site appears to freeze, I go and look at the
> database threads and one thread has a status of "UPDATE WAITING" and the =
the
> others are sitting in the normal idle in transaction status.  The server =
is
> idle (2% or less cpu) and the drives are as normal, silent.  The server is
> doing absolutely nothing.
>=20
> I also found out how to lock it up every time.  I have a specific page th=
at
> does some intensive database work including some updates to some preferen=
ce
> tables as well as some reads of some large tables, etc.  If I go to that
> page and then hit F5 twice in succession, it locks up the system every ti=
me
> requiring a zope restart.
>=20
> Now I am starting to think that we are running into a concurrency issue w=
ith
> postgres and transactions.  I was wondering if anyone with a bit more
> experience might be able to shed some more light on the situation and/or
> where I might look to further debug the situation.
>=20
> My hunch is that the following happens:
> 1. First request comes in.
> 2. User presses F5 before the first transaction finished.
> 3. Browser drops first connection and reconnects.
> 4. Zope starts to write to the socket, notices that the browser is no lon=
ger
> connected.
> 5. Zope aborts the transaction.
> 6. BUT, the database never get's a rollback and simply waits in the
> transaction for ever.
> 7. Unfortunately, this must also cause some locks that don't allow any ot=
her
> thread to do any work.
> 8.  Restarting Zope closes those db connections and postgres roles the
> transaction back.
>=20
> Does anyone have any further suggestions on how to debug this further or =
to
> stop the problem?
>=20
> -Chris
>=20
> RH 7.2
> Zope 2.4.1
> ZPoPyDA
> Postgres 7.1.3
> ------------------------------
> Chris Kratz
> chris.kratz@vistashare.com
>=20
>=20
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -=20
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )

--=20
Christian Theune - ct@gocept.com
gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt
tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981

reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])