[Zope3-dev] Re: [ZODB-Dev] revise transaction API

[Jeremy Hylton]

On Tue, 2004-03-16 at 20:02, Christian Robottom Reis wrote:
> Comments on http://zope.org/Wikis/ZODB/ReviseTransactionAPI

Thanks for the comments.  PyCon intervened and delayed my response.

>     - It may make sense to describe the setLocalTransaction issue in the
>       =Current transaction= section. When setLocalTransaction is called,
>       you effectively have one transaction per resource manager, which
>       means the answer to "What is the current transaction?" is linked
>       to the answer to "What is the current resource manager?"

I think we should be able to pass a transaction manager to open and
achieve the same result as setLocalTransaction().

>     - Shouldn't the Extended transaction API describe ways to get the
>       changes participating in the transaction? Something like
>       get_modifications() (that might in the ZODB case return OIDs which
>       are materialized by the resource manager)?

Yes.  We definitely need a better API for inquiring about the status of
a transaction, where status is broadly construed.

>     - I don't have a [non-contrived] usecase for suspend/resume in my
>       application set.

We're not planning to implement it for 3.3.  In the absence of user
requests, it doesn't have much priority.  But the implementation is easy
to explain, so it does get a little priority.

>     - There's a question:
> 
>         (It's an error to modify an object when there is no transaction?)
> 
>       Isn't this sort of answered by the text in =Current transaction=?
> 
>          A particular manager could implement the policy that get()
>          called before new() returns None or raises an exception.
> 
>       The way I see it the ZODB's default resource manager would specify
>       this behaviour (and I think yes, it should complain).

The default transaction behavior for ZODB 3 is to create a new
transaction if get() is called when there is no current transaction.  So
it would be a change in semantics to complain.  I think it would be nice
to have the option of using explicit creation, though.
    
>     - "I like the ZODB 4 names and approach prepare()" -> do you mean "I
>       like the ZODB 4 names approach() and prepare()"?

I actually just meant prepare().  In ZODB 4, the transaction manager
calls prepare() on each resource manager.  Then it calls commit() or
abort().  The transaction manager doesn't have methods like tpc_begin(),
tpc_vote(), etc.  On the other hand, it doesn't support subtransactions
either.

After implementing subtransaction support on the jeremy-txn-branch, I
realized there is a substantial benefit of using a savepoint() method
independent of the transaction commit() call.  It keeps all the
savepoint mechanics out of the transaction code, which makes the code
for each feature simpler and easier to understand.

>     - It would be nice to see the equivalent of savepoint in 3.3.. 

since commit(1) and abort(1) should be functionally equivalent, I don't
think we'll get savepoints in 3.3.

>     - I don't quite get what the Third clause is for in =ZODB
>       Connection and Transactions= -- in what situation would a
>       Connection want to provide a specific resource manager?

It's actually the use I mentioned about as an alternative to
setLocalTransaction().  Perhaps you got confused about transaction
manager vs. resource manager; the Connection is a resource manager.

>     - Currently (in HEAD), if you close() the connection, modifying
>       objects and manipulating transactions gets you a number of
>       interesting exceptions raised. I had a patch that cleaned this up
>       somewhat, but it was simplistic (and nobody commented on it)

We'll definitely fix this.

> The three features which we *really* miss in the ZODB, and which
> influence the way we write applications significantly, are, in order of
> importance:
> 
>     1. savepoints,
>     2. partial invalidations (something like a partial sync() where only
>        a subset of the objects are invalidated, without modifying the
>        other objects in the transaction),
>     3. getting all modified objects (inclusing those in subtransactions).
> 
> I don't see anything like 2. accounted for in the text, but I'm not sure
> if it's relevant here , and if it is, how it would fit in to the
> proposed APIs.

The problem with partial invalidations is that they provide an
inconsistent snapshot of the database state.  In other words, we used to
provide partial invalidations before we implemented atomic invalidations
;-).  It lead to corrupted databases.

Jeremy