Information Technology Reference
In-Depth Information
F IG . 6. Method replay synchronization.
method replay is unsuccessful). Whether a method replay is successful depends
solely on the application's business logic: i.e., on whether the method throws an
exception when invoked on the server.
Conflict resolution : the exception that caused the method to fail, when replayed
on the server, is logged and the user is informed of the error. The conflict must
be resolved manually.
Transactional merge : the disconnected work is transparently applied to the
server through successful method replay.
Figure 6 sketches what happens during a successful method replay synchronization
for the disconnectable order entry application. In contrast to the process shown in
Fig. 5 , only the method call that decremented the stock of staplers is logged. That
method - which does not include the resulting stock level—is replayed on the server,
and results in similarly decrementing the server-side stock of staplers. This figure
corresponds to the scenario in which sufficient stock is shown in both the client-
side database (during disconnected execution) and the server-side database (during
synchronization) to fulfill the customer's order. In contrast to the data replication ap-
proach, the fact that three staplers were shown in the client-side database, but only
two in the server-side database, is irrelevant: the order will be successfully com-
mitted to the server so long as the customer ordered fewer than the two staplers
that are available on the server. The “order” business logic simply checks (on both
the client and the server) that sufficient stock exists to fulfill the order, and does
not verify that the stock levels of the client-side database match that of the server-
side database. Consider, however, the scenario in which sufficient stock is shown in
the client-side database (during disconnected execution) but the server-side database
Search WWH ::




Custom Search