Information Technology Reference
In-Depth Information
this leads to a serializability violation that was not caused by the application logic.
Regardless, enhancing data replication implementations to also validate an applica-
tion's read sets is relatively straightforward, and is not a fundamental limitation of
the algorithm.
The key difference between the transactional models of data replication and
method replay is more subtle, and involves the definition of transactional isola-
tion. Data replication synchronization ideally attempts to ensure that the device's
transactions are
conflict serializable
[15]
with the transactions that were previously
committed on the server. This criterion is defined in terms of read and write opera-
tions on data. Method replay attempts to ensure that
transformations
performed on
the device are compatabile with transformations previously committed on the server.
In effect, transactions executed on the disconnected device are
delayed
to a later point
in time: namely, the time at which synchronization occurs. They are guaranteed to
be serializable with the server-side transactions because, from the shared database
viewpoint, they are executed
after
all the connected transactions have executed, and
using any data modified by the server-side transactions as their inputs. Thus, strictly
speaking, there cannot be a serializability violation. Under method replay seman-
tics, the fact that work executed on a disconnected client is (almost) irrelevant to the
transaction model. From a developer's viewpoint, therefore, the programming model
is projected more consistently; from the client's viewpoint, the work executed against
the most current version of the data.
The only caveat to the method replay transaction model is that any “human input”
into the disconnected client transactions may not be replayed accurately, because
the human thought processes are not captured in the method implementations. For
example, the user may have looked at her checking balance on the disconnected
client, seen a balance of $1000, and decided to withdraw $100. When the discon-
nected transactions are replayed on the server, the balance may have been $101.
The replayed method will withdraw $100, leaving $1, but had the user known she
only had $101 she may have decided to withdraw $50, or nothing. Also, she thinks
her new balance is $900, which does not represent the balance at any time in the
shared database. Typically, however, business logic will prevent a withdrawal of
an amount greater than the available funds at synchronization time, unless over-
drafts are permitted. Thus the synchronization process will not result in database
consistency violations, unless the application is flawed. Note also that these “hu-
man serializability violation” scenarios occur with data replication as well. Data
replication algorithms typically do not verify that data which was read but not mod-
ified by the disconnected client is unchanged on the server at synchronization time
(in fact we are not aware of
any
data replication system which does this verifica-
tion).
