Shane Hathaway wrote at 2008-1-31 11:55 -0700:
> ...
>Yes, quite right!
>However, we don't necessarily have to roll back the Postgres transaction
>on every ZODB.Connection close, as we're doing now.

That sounds very nasty!

In Zope, I definitely *WANT* to either commit or roll back the
transaction when the request finishes. I definitely do not
want to let the following completely unrelated request
decide about the fate of my modifications.

> If we leave the
>Postgres transaction open even after the ZODB.Connection closes, then
>when the ZODB.Connection reopens, we have the option of not polling,
>since at that point ZODB's view of the database remains unchanged from
>the last time the Connection was open.

Yes, but you leave the fate of your previous activities to
the future -- and you read older and older data
which must increase serializability problems (Postgres might
not garantee serializability even when the so called isolation
level is chosen; in this case, you may not see the problems
directly but nevertheless they are there).

>It's not usually good practice to leave sessions idle in a transaction,
>but this case seems like a good exception since it should significantly
>reduce the database traffic.

I agree that it can reduce traffic but I am almost convinced that
the price will be high (in either "cannot serialize concurrent updates"
or not directly noticable serializability violations).

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to