Comment 6 for bug 279945

I'd go so far to say that only bothering with the main threaded transaction manager would be sufficient for the threaded use case. If you disagree, see my first preference, below for a possible story.

For API, I have a first-, second-, and third-place preference.

1) Have a version of ZStorm (name TBD, though I like Stores or StormStores) that requires an explicit transaction manager. ``_local`` is not around: the dicts that normally hang off ``_local`` are on the ZStorm instance itself. Make the current ZStorm a subclass of that, which does not accept a transaction manager (using the threaded transaction manager) and uses _local. If you really think we ought to accept other threaded transaction manager instances or implementations, they could be even acceptable as optional arguments to ZStorm.

2) Alternatively, have a single ZStorm. If you pass in an explicit transaction manager, it assumes you are not threaded, and doesn't use _local. Otherwise, it uses the standard threaded transaction manager and _local.

3) Alternatively, what you said. :-)