Information Technology Reference
In-Depth Information
will cause useful work performed on the device to be discarded, or will require man-
ual intervention to fix. Because data replication performs synchronization in terms of
low-level data (where it is difficult to introduce higher-level semantics or application
logic), it is more likely to create such false conflicts than method replay.
To see why this is so, consider the
order entry
example, and note that two clients
may concurrently decrement the stock level for the same item. Data replication syn-
chronization sees these actions as conflicting: different clients have modified the
same row of the database. The middleware
must
flag this as a conflict, because
this will lead to a transaction serializability violation (one of the clients' updates
will be a
lost write
[15]
). From the perspective of the application, however, the
desired semantics are merely that sufficient stock exists during synchronization
to satisfy the order. The precise stock level value for a given item is irrelevant.
These semantics are easily expressed by a connected version of the application.
They are also easily expressed for a disconnected version that uses method re-
play. In fact, only one version of the application need exist, since the identical
purchaseOrder
method executes for both connected and disconnected envi-
ronments, decrementing the stock levels appropriately, and validating only that
(0 != stockLevel)
. The same method—with the same validating business
logic—that executed and was logged on the device, is replayed on the server dur-
ing synchronization. Disconnected versions of the application that use data repli-
cation synchronization must use different semantics: stock levels during synchro-
nization must be identical to their levels during disconnected execution. Because
application-independent data replication middleware does not have enough semantic
information about the application to resolve this automatically, synchronization will
fail.
5.3.2
Consistent PM Projection
Advocates of data replication may counter that the previous argument is naive.
The sort of false conflicts described above can be easily avoided by adding business
logic as necessary to the synchronization engine. The middleware makes application-
specific synchronization “hooks” available to developers in order to explicitly com-
pensate for (and resolve) such false conflicts. The synchronization hooks could
(reasonably) assume that applications only increment and decrement stock levels,
and thus could determine the stock level that would result from the synchronization
of multiple transactions.
However, this starts the synchronization middleware down the path of understand-
ing the application semantics. Maintaining business logic in both the application and
synchronization middleware is problematic, to say the least. The synchronization
business logic is placed in the position of trying to reverse-engineer the changes made
