Comment 2 for bug 279945

On Fri, 2008-10-10 at 10:49 +0000, James Henstridge wrote:
> First of all, the zstorm code is explicitly designed to manage per-
> thread stores, so working with the standard threaded transaction manager
> seems appropriate. That said, some bits of code could be reused with
> other transaction managers (e.g. the DataManager implementation).
>
> What sort of API are you looking for, and what sort of problems are you
> trying to solve?

The API: something to which you can explicitly pass in a transaction
manager, perhaps optionally (it would default to the threaded
transaction manager). This would give you an object fulfilling the
IZStorm interface, tied to the data manager.

The problems:

- It sometimes comes in handy in tests to be able to show how
simultaneous interactions work. Doing this with threads is possible but
comparatively quite painful to simply using separate data managers.
See, for instance, the conflict resolution part (second half) of the
doctest here:

http://pypi.python.org/pypi/zc.queue

- non-threaded use of the API could come in handy when using APIs such
as Twisted's. This is done in my project zc.async with ZODB transaction
use, for instance.

As you can see, the concerns are somewhat theoretical--I don't have a
project that needs this change now in Storm, though I have used a
similar feature before with the ZODB and the transaction module.

The change I propose would definitely provide better compatibility with
the transaction module. I perceive the Zope 3 project, like others, to
be moving towards library reuse, rather than framework reuse. I hope
Storm is interested in that sort of approach as well. What Storm has
now is sufficient for Zope-3-the-framework, but the transaction module
has wider applicability and wider use.