The old code would avoid hosing the system when the first jar failed
during its finish.  The logic is that the failure means that
transaction did not commit, so it was safe for all the other jars to
abort.  There are counter-examples to this assumption.  For example,
ZEO could fail after commiting the transaction on the server but
before communicating that success to the client.  It would lead to
inconsistency if the other jars aborted after the first committed.

The solution is to reduce the special case yet further:  If a
single-jar transaction fails during the finish, assume the transaction
is aborted and avoid hosage.  If the jar actually committed, it's
possible to get back to a consistent state since only one jar was
involved.