[ZODB-Dev] ZODB 3.2.4 ConnectionStateError

[Tim Peters]

[Tim Peters]
>> In all the examples, abort() was done in a "finally": clause, or in an
>> "except:" clause that ended with "raise".  A "finally:" clause is
>> executed regardless of whether an exception occurs, but if an exception
>> does occur, "finally:" doesn't suppress the exception.  When the
>> "finally:" suite ends, the exception is propagated (unless an exception
>> also occurs during the "finally:" suite's execution, in which case that
>> new exception gets propagated instead).

[Syver Enstad]
> I know the error will propagate, but it won't stop my server like running
> out of connections will,

We're not communicating, but I don't know why.  I would say that running out
of connections would hang your server.  By stopping a server (or any other
program), I mean the process exits -- the process no longer exists.

If you run out of connections, the server will hang -- or at least one
thread will block until (if ever) one of the open connections is returned to
the pool.  It won't cause any threads to die.

If no higher-level code *eventually* catches and suppresses a conflict
error, the thread in which the exception was raised will cease to exist.
That's the normal outcome from any exception that isn't caught and
suppressed, in any Python program (ZODB or not).

> and the next user of the connection won't have any side effects from
> the ConflictError.

Provided the transaction was aborted, and the connection was closed, and the
process survives, yes.  When a thread with an unhandled exception goes away,
exactly what happens depends on a lot of details we haven't mentioned here
yet (main thread vs. child thread; thread module vs. threading module;
daemon threads vs. non-daemon threads; and the operating system).
 
> Am I correct in assuming this?

I really don't know.  You appear to be assuming something I can't figure
out.  Do you, or do you not, have higher-level code that will eventually
catch and suppress the conflict errors propagated out of all the example
code shown so far?  If you don't, then probably not:  a thread in which a
conflict error occurs will cease to exist shortly thereafter, and the entire
process may, or may not, vanish along with it.  If you do, then maybe you're
OK.  In either case, it depends on code beyond any code yet shown or
described.