[Persistence-sig] "Straw Man" transaction API

[Sebastien Bigaret]

>     My opinion here is that we shouldn't try to handle multi-backends commits
>     as a whole -- some backends simply makes it almost impossible. But: this
>     should be clearly stated.

More on this: what do you think of the following possible additions to the API?
(This is just a quick draft)

    NB: TP Monitoring stands for Transaction Processing Monitoring

- 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

- to class Transaction:

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

      """

--> With such an API, we could then make sure that, when
    isTPMonitoringEnabled() evaluates to true, the commit() phase in a
    Transaction ensures that it does all the changes or rollbacks everything.
    (e.g. by beginning a top-level transaction in each participants, via the
    appropriate API --to be defined--, and by committing this top-level
    transaction at the end of the commit phase, when everything has gone
    smoothly).


Last note: I'm not positive at all about canBeTPMonitored being equivalent to
  the ability of using/simulating nested transactions ; I have the feeling
  that at least the latter implies the former. 
    For RDBMS it seems OK, for file-based storage this could be emulated
  through concurrent versioning, but the general case is quite a bit beyond
  my knowledges. And this is not something I already played with but just a
  dream of mine, so people having real experience with TP monitoring processes
  can go and grab their flamethrowers now!

  
-- Sebastien.