[Persistence-sig] "Straw Man" transaction API

Phillip J. Eby pje@telecommunity.com
Mon, 15 Jul 2002 17:46:54 -0400


At 04:18 PM 7/15/02 +0200, Sebastien Bigaret wrote:
>
>- to class Participant:
>
>    canBeTPMonitored(self): # or supportNestedTransactions() ?
>      """
>      Tells whether the participant can be integrated into a TP monitoring
>      process. Valid answers are:
>
>        - YES ; e.g. RDBMS that support nested transactions will definitely
>          answer yes.
>  
>        - NO
>  
>        - NOT_APPLICABLE ; e.g. for listeners

I'm pretty sure that this terminology is not accurate.  Nested transactions
and multi-phase commit aren't really related, AFAIK.  It's quite possible
to support either one without the other.

If we're going to have introspection for multi-phase commit, I'd rather
have something like 'canVote()', with the response being False if the
participant can raise errors during commit_txn(), or true if the
participant guarantees it will not fail on commit_txn() if it didn't veto
commit during the voting phase.


>- to class Transaction:
>
>    def isTPMonitoringEnabled(self):
>      """
>      Answer is true if all participants answer 'YES' or 'NOT_APPLICABLE' to
>      'canBeTPMonitored', false otherwise.
>
>      """

This is a YAGNI, I would say; the transaction is the only party that needs
to know about its participants' voting capabilities.  But it might be
useful to expose a 'canRevert()' introspection on the transaction, that
would tell us if all the participants support reverting to a savepoint.
That information would be useful outside the transaction.