12.4. Multiple databases and devices

We can analyse the MyContexts application in terms of three parts:

  • an interface (graphical, as it is, but not necessarily so),

  • a database

  • and a component that sits between the two.

This latter component

  • receives instructions given by the end user through the interface on how to modify, delete or extend contexts and roles;

  • saves new versions of those contexts and roles to the database

  • compiles and sends transactions of deltas for each peer that should be informed about those changes. A delta is an atomic change to a context or role; however, some deltas must be carried out together in order for the data to remain consistent, hence the notion of Transaction.

In this text we focus on the question: can an end user be meaningfully supported by a constellation of more than one UI, database and middle component? This will concern mostly the transaction handling aspect of that component, so here we call it the Transaction Handling Point or THP.

The Perspectives Distributed Runtime is a THP; but a THP need not be a PDR, as we will see later.