Where it makes more sense. Hysterically, it didn't matter because one
was an alias for the other.

For safety, closing the database aborts transaction managers
associated with open connections.  In explicit mode, this can lead to
NoTransaction errors.

It's likely a bug for DB objects to abort transactons on
close.  This needs more thought.

  resources after transaction complete.  See:
  https://github.com/zodb/relstorage/issues/147

- Take advantage of the new transaction-manager explicit mode to avoid
  starting transactions unnecessarily when transactions end.

Don't manipulate Connection state after it has been returned to the pool.

Good catch. Thanks.

Doing so leads to race conditions.

In particular, there can be an AttributeError.

See https://github.com/zodb/zodbshootout/issues/26 for details.

Don't require persistent at setup time. We don't build native code th…

Don't require persistent at setup time. We don't build native code that needs those headers anymore. Fixes #119.

Connection.new_oid delegates to its storage, not the DB.

Fixes #139

Fixed: ZODB.Connection.TransactionMetaData didn't custom data

  storage that some storages rely on.

sigh

transaction user and description: text above, bytes below

Also added _s to _transaction_meta_data_text_variables and
_text_transaction_info to mark them as private.

Conflicts:
	CHANGES.rst

WRT travis and winbot.

Conflicts:
	doc/guide/transactions-and-threading.rst

for user_name and description

Cleaned up check_checkCurrentSerialInTransaction