Transaction Processing, Package Deals, and Common Transactive Services

[wtcox <wtcox@coxsoftwarearchitects.com>]

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: wtcox@CoxSoftwareArchitects.comÂ

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

+1 862 485 3696 mobile