Information Technology Reference
In-Depth Information
by the application logic, so that it can reconcile the data. More importantly, how-
ever, the more that such special-purpose logic must be added by
developers
—rather
than being performed automatically by middleware—the more the programming
model's consistent projection is compromised. While making the application discon-
nectable, it forces developers to explicitly “code around” the issue of disconnected
operation. More pragmatically, rather than maintaining a single version of the ap-
plication that can be deployed to both connected and disconnected environments,
the business must now maintain two (or one and a half) versions of the applica-
tion.
5.3.3 Execution Against Current Data
Because business applications must behave transactionally, a transaction model
is part of any programming model for business applications. At a high-level, both
data replication and method replay offer the same transaction semantics. In terms
of the taxonomy presented in
[12]
, both use a detection-based algorithm, with
deferred validity checking, and invalidation when notified by the server about
an update. (This approach is sometimes termed “optimistic,” in contrast to pes-
simistic, lock-based, concurrency control mechanisms.) This enables high server-
side availability—despite long periods of disconnection or even device failures—
because the server is not forced to avoid potential conflicts.
Similarly, both approaches enable the connected transaction model to be projected
to disconnected devices.
EJBSync
, for example, presents a disconnected device with
the J2EE/EJB transaction model: sections of code can be explicitly demarcated with
a
UserTransaction
, or the developer can use declarative transactions on a per-
method basis. Transactions that are rolled back on the disconnected device are not re-
played on the server (since the LogRecords are not committed). During synchroniza-
tion, the transaction boundaries created during the client's execution are preserved
on the server, as is the original transaction ordering. Data replication, as well, can
project the connected transaction model to a disconnected environment. Although
DB2 Everyplace sync does not maintain an application's transaction boundaries or
ordering, this is a limitation of the implementation—not that of the idealized algo-
rithm. Gold Rush, for example
[14]
, shows that mobile transaction middleware can
do data replication synchronization and preserve transaction boundaries and order-
ing. A similar situation holds with respect to validating “read sets”—the set of data
read, but not written, by the application. Data replication implementations validate
that conflicts have not occurred with respect to the application's “write set,” but do
not appear to check whether other users have concurrently modified the synchroniz-
ing device's read set. Although this can theoretically lead to a violation of transaction
isolation
[15]
, in practice, we find it difficult to identify a realistic scenario in which
