Information Technology Reference
In-Depth Information
The updates are made using optimistic concurrency control, so that incompatible
database changes made during the user interaction (e.g., by other users and/or appli-
cations) will be detected, and the transaction will be aborted.
A close reading of the SDO literature shows that the use-cases rely on continu-
ous connectivity between the application, the DAS, and the database. If the DAS is
collocated with the application, it cannot access the database during disconnected op-
eration. Conversely, if the DAS is collocated with the database, it cannot be accessed
by the disconnected application.
One possible way in which disconnected applications could be implemented on the
current SDO architecture would be to have the application avoid making calls to the
DAS while disconnected. In this scenario, the application would make a call to the
DAS before disconnection, and the DAS would return the database subset of interest
to the client. The first difficulty with this approach, is that the application almost
certainly already has most of the database subset (from the previous disconnection).
There is no mechanism within the current SDO architecture to conveniently retrieve
only the incremental changes to a data graph, and automatically merge them with the
outdated (but mostly correct) version of the data graph.
Another difficulty is that, upon reconnection, the application would need to pass
the entire database subset (as a data graph) to the DAS. Thus, the unmodified portions
of the data graph would also need to be communicated to the DAS. Within the current
SDO architecture, there is no way to serialize only the change log and updated values
of the datagraph.
Thus, although the DataGraph and DataObject APIs support a good client pro-
gramming model, these difficulties suggest that a reasonable approach to supporting
disconnected applications with the SDO architecture would require placing addi-
tional middleware between the application and the existing DAS. Since the DAS
interface is currently undefined, we propose that the new client-side middleware be
architected as a DAS which provides disconnected client support (see
Fig. 8
). The
server-side DAS is used only by the client-side DAS, and provides whatever API is
needed by the client-side DAS.
Since multiple (disconnected) client-side transactions would now need to be prop-
agated to the server, presumably, the SDO architecture would be enhanced with an
API or annotations to specify how changes to the data graph are interleaved with
transactional behavior. A possible approach would to simply incorporate technolo-
gies such as the Java Transaction API (JTA
[23]
) “by reference.” This would re-
quire developers to explicitly control transaction activity through
begin
,
commit
,
and
rollback
commands. It would harder for the programming model to supply
declarative transactions in the way that EJBs do (to seamlessly integrate session and
entity transactional activity) since SDOs do not include business logic (Section
4.3
).
