Transaction Processing, Package Deals, and Common Transactive Services

In passing we've talked about transaction processing, which is
      related to database access. This brief note is to talk about TP,
      its implications for and uses in Transactive Energy, and their
      relationship.

    
We often hear about someone wanting to ACID properties for
      database systems - atomicity, consistency, isolation, and
      durability - which are strictly speaking properties of a
      transaction processing system usually integrated with a database.
      

    

    
Atomicity links selected operations into one that happens or
      doesn't; there are other techniques including rollback to undo a
      partially executed transaction, in effect unwinding the components
      of a transaction.

    

    
TP ACID characterisics assume and in fact require a
      tightly-coupled system. They cannot easily be implemented in
      loosely-coupled systems. For those, there's a family of
      "distributed agreement protocols" where one must compensate for
      actions already committed rather than unwind or undo them.

    
A distributed agreement protocol cannot unwind or undo a
      committed action -- if a partial interactions has already (say)
      bought 10 kWh of electricity, then the unwinding participant must
      sell 10kWH - a compensating action.

    
Why is this important?

    
If you want to buy a load curve (a set of purchases in contiguous
      time intervals), you'd like to get all or none, but in a
      distributed world, you may have bought all but one then to unwind
      you'd have to sell all those you bought. 

    

    
In effect, loose coupling makes TP semantics hard to implement.

    

    
The implication is that in a CTS environment, you can't do a
      two-level "package deal" where you buy (say) 10 kWh at 2pm AND
      sell or buy 20 kWh at 3pm - these are independent.

    
So you'd either apply a distributed agreement protocol, or deal
      with a party that may have all the pieces - and combines them as a
      single purchase. Either is out of scope for CTS.

    

    
Also for the specification, if an EiCreateTender has a stream of
      values and prices, we can't presume that it's an all-in-one
      purchase; instead we must understand that they are independent,
      and that we cannot rely on an underlying loosely-couple systems to
      undo or rewind a partial set o transactions.

    
Thanks!

    
bill

    

    
-- 

      
      
      
      
      
      
      
William CoxÂ

      
Email: [email protected]Â

      
Web: http://www.CoxSoftwareArchitects.comÂ

      
+1 862 485 3696 mobile