[ZODB-Dev] ZODB 3.2.4 ConnectionStateError

[Syver Enstad]

"Tim Peters" <tim at zope.com> writes:

> > Am I right in assuming that the connection.sync() call I always do is no
> > longer needed in 3.2.4?
> 
> Sorry, I can't guess.  Why were you calling it before?  Possibilities
> include:
> 
> - You're running a ZEO client, not running an asyncore mainloop, and
>   needed to sync() manually in order to process invalidation messages
>   from the ZEO server.  If so, then you still need to sync() manually.

This is true, I am not running a ZEO client in production but I have
been experimenting with it.

> - You're calling sync() "because it didn't work otherwise"; i.e., you
>   don't know why you were calling it, you just know that things worked
>   better when you did.

I wanted to be sure that modifications without commit were discarded
so that state changes in objects didn't "leak" into unrelated
applications (the next DB.open call). I first assumed that close would
be enough, but it wasn't so I tried different approaches as far as I
remember sync was the most reliable. (I can't remember if abort was
equally good).


> > Is it safe to access objects in the connection after one has called
> > abort?
> 
> You're never *not* "in" a transaction.  The instant abort() returns, a new
> transaction has implicitly begun.  So, yes, it's safe to access objects
> after aborting, but you're technically in a new transaction then.  If you
> modify any of these objects, you'll again need to abort or commit the
> transaction before closing the connection.

Good so basically my code should work with 3.2.4 as far as I can
see. It's safe to not abort the connection at the end, because if I
get the ConectionStateError I obviously have a bug in my source code
because code that I assumed to not change state in the database did in
fact do that.

Thanks again for doing the hard work of cleaning up ZODB!