Transaction

==================

Added a transaction-manager explicit mode. Explicit mode makes some
kinds of application bugs easier to detect and potentially allows data
managers to manage resources more efficiently.

(This addresses https://github.com/zopefoundation/transaction/issues/35.)

==================

- The user and description fields must now be set with text (unicode)
data. Previously, if bytes were provided, they'd be decoded as
ASCII. It was decided that this would lead to bugs that were hard
to test for.

Also, the transaction meta-data field, ``extended_info`` has been
renamed to ``extension``.

==================

- Fixed: Some legacy applications expect the transaction _extension
attribute to be mutable and it wasn't.

==================

- The transaction ``user`` and ``description`` attributes are now
defined to be text (unicode) as opposed to Python the ``str`` type.

- Added the ``extended_info`` transaction attribute which contains
transaction meta data. (The ``_extension`` attribute is retained as
an alias for backward compatibility.)

The transaction interface, ``ITransaction``, now requires
``extended_info`` keys to be text (unicode) and values to be
JSON-serializable.

- Removed setUser from ITransaction. We'll keep the method
indefinitely, but it's unseemly in ITransaction. :)

The main purpose of these changes is to tighten up the text
specification of user, description and extended_info keys, and to give
us more flexibility in the future for serializing extended info. It's
possible that these changes will be breaking, so we're also increasing
the major version number.

==================

- Added a transaction-manager ``run`` method for running a function as a
transaction, retrying as necessary on transient errors.

- Fixed the transaction manager ``attempts`` method. It didn't stop
repeating when there wasn't an error.

- Corrected ITransaction by removing beforeCommitHook (which is no longer
implemented) and removing 'self' from two methods.

==================

- Fixed: Synchonizers that registered with transaction managers when
transactions were in progress didn't have their newTransaction
methods called to let them know of the in-progress transactions.