Patent Application
20060010130
The present invention relates generally to application-based transaction processing, and relates more particularly to the synchronization of transactions executed by a client while operating on a limited connection to a server with the server's current state.
When a full connection is re-established, changes made to the cached server state by the client must be synchronized with a current server state. One conventional way to accomplish this is to copy the modified state data from the client to the server. A problem with such conventional techniques, however, is that they maintain neither the transactional boundaries that existed on the “disconnected” client, nor the transactional order that existed on the disconnected client. In addition, client transactions that are committed to the server were originally committed against a state that is no longer current with respect to the server. Moreover, certain dependency cycles that correspond to invalid transactions are not detected, meaning that the corresponding transactions are improperly committed. Finally, certain transactions are aborted because the client state conflicts with the current server state, yet if the transactions were run against the current server state, they would execute properly.
Thus, there is a need in the art for a method and apparatus for synchronizing client transactions executed by an autonomous client.
In one embodiment, the present invention is a method and apparatus for synchronization of client transactions executed by an autonomous client. One embodiment of the present invention enables a client operating on a limited connection to a server to log transactions executed against a locally stored server database state. Logged transactions are then synchronized with a current server database state by delivering the transaction log to the server, which re-executes each logged client transaction against the current server database state, thereby reducing synchronization-related transaction conflicts.
So that the manner in which the above recited embodiments of the invention are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be obtained by reference to the embodiments thereof which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.
In one embodiment, the present invention is a method and apparatus for synchronization of client business logic executions (e.g., business transactions and methods) executed by an autonomous client. Embodiments of the present invention enable a client operating on a limited connection to a server to log transactions executed against a locally stored server database state. Logged transactions are then synchronized with a current server database state by delivering the transaction log to the server, who re-executes each logged client transaction against the current server database state, thereby reducing synchronization-related transaction conflicts.
For the purposes of the present invention, the term “limited connection” may mean that the client is completely disconnected from the server, or that the connection is simply too limited (e.g., due to slow speed or high latency) to allow the client to send updates to the server after every transaction. For example, if the client is executing on a mobile computing device such as a personal digital assistant, a cellular telephone or a hand-held or laptop computer, the device typically will operate, at least part of the time, without interacting with the server. Embodiments of the present invention are described in terms of transactional applications, e.g., business applications, which are characterized by periodic updates to a state, e.g., stored on a server, which is shared by multiple clients, wherein the updates are performed transactionally.
The method 200 is initialized at step 202 and proceeds to step 204, where the method 200 receives a copy of the current server database state (or a relevant subset thereof) from the server. For example, in one embodiment, one transactional application residing at the client is an order-entry application (e.g., for ordering items for purchase), and a corresponding server database state might comprise one or more of orderable items, customers, stock levels and pending orders. A database state received in step 204 may comprise a subset of this information (e.g., only information pertaining to customers serviced by the receiving client).
In one embodiment, the method 200 receives the current server database state data in response to a request issued to the server. In one embodiment, step 204 is executed while the client is fully connected to the server. In one embodiment, a “full” client-server connection is one in which latency and bandwidth permit the client to synchronize with the server within a reasonable period of time, where a “reasonable” period of time is defined by the transactional application that is executed and the device being used to execute the transactions (e.g., a reasonable amount of time could be a matter of minutes for a portable device, or overnight for a departmental server) In one embodiment, step 204 includes receiving all current server database state data that is relevant to the transactional applications that the client is currently executing. In one embodiment, the client stores the received server database state data on a local database (e.g., a persistent client database) that is accessible by the one or more transactional applications to modify the server database state data contained therein.
In step 206, the method executes one or more transactional applications against the stored server database state that was received in step 204 and logs each transaction (e.g., logs business logic executions for each transaction). In one embodiment, logging of the transactions in step 206 captures the execution of business logic on the client, as opposed to merely values (e.g., before or after) of the database records. Thus, a log entry for each transaction includes enough information to allow the server to replay or re-execute the transaction at a later time, as discussed in further detail below. In one embodiment, a log entry for each transaction includes at least one of the following: a name (or other identifier, e.g., “PlaceOrder”) for the transaction, input parameters for the transaction (other than the resultant database state, e.g., set of [item, count], customer identifier), and the transaction's result value. In one embodiment, the transactional applications are executed and logged while the client is operating over a limited connection to the server (e.g., the client is operating substantially autonomously). In one embodiment, each transaction is executed and logged by logging middleware residing on the client that tracks the methods of the transactional applications as they execute.
In step 208, the method 200 decides whether or not to synchronize the client's log of executed transactions with the server (e.g., with a current server database state). In one embodiment, the decision to synchronize the log of executed transactions is based on the availability and/or the quality of a network connection between the client and the server (e.g., in one embodiment, if a high quality connection is available, the method 200 chooses to synchronize). If the method 200 decides not to synchronize the client's log with the server, the method 200 returns to step 206 and continues to execute and log transactional applications. Alternatively, if the method 200 does decide to synchronize the client's log with the server, the method 200 proceeds to step 210, where the method 200 reconnects (e.g., re-establishes a full connection from) the client to the server and delivers the log of executed methods to the server.
The log of executed methods is received and processed by the server as described in further detail below with reference to
Once the method 200 receives the status update, the method 200 proceeds to step 214 and deletes the client's locally stored server database state data (e.g., the now-outdated server database state data received from the server in step 204). The method 200 then returns to step 204 and receives an updated copy of the server database state (e.g., the now current state) so that the method 200 can continue to execute one or more transactional applications. In one embodiment, the method 200 optimizes execution of step 214 and the subsequent return to step 204 by deleting only obsolete or out-dated state data in step 214.
The method 300 is initialized at step 302 and proceeds to step 304, where the method 300 executes server transactions, e.g., in accordance with a default server state. In step 306, the method 300 determines whether or not a request for current server database state data has been received, e.g., from a client. If the method 300 concludes that such a request has been received, the method 300 proceeds to step 308, where the method 300 replicates or copies the current server database state and sends the replicated data to the requesting client.
Alternatively, if a request for current server database state data has not been received, the method 300 proceeds to step 310 and determines whether or not a request to replay a particular client's transaction log has been received. If no such request has been received, the method 300 returns to step 304 and executes server transactions, e.g., in accordance with the default state.
However, if the method 300 concludes in step 310 that a request to replay a particular client's transaction log has been requested, the method 300 proceeds to step 312 and receives the relevant transaction log from the requesting client (e.g., where the client has logged transactions made while operating over a limited connection to the server in accordance with step 206 of the method 200). The method 300 then proceeds to step 314 and re-executes the logged methods from the received transaction log against the current server database state. In one embodiment, the logged methods are re-executed one-by-one until all logged methods have been re-executed against the current server database state. In one embodiment, replay middleware residing at the server enables the server to process the client's logged transactions.
In one embodiment, re-execution result values are compared against original client result values logged for each transaction, and comparison results indicate whether or not the re-execution is valid according to pre-defined criteria.
In step 316, the method 300 delivers a status report of the re-execution/synchronization step 314 to the client whose log was re-executed. The method 300 then returns to step 304 and executes server transactions, e.g., in accordance with the default state.
Thus, rather than simply uploading a modified database state from the client (which will likely not reflect the server's actual current database state), the server uploads the transactional methods executed by the client against the stored database state. Because the client transactions are then individually re-executed against the current server database state rather than automatically committed against the current server database state en masse, transactions may be more readily evaluated before they are erroneously committed or aborted. This also enables original transaction boundaries to be maintained and substantially eliminates dependency cycles.
Alternatively, the transaction synchronization module 405 can be represented by one or more software applications (or even a combination of software and hardware, e.g., using Application Specific Integrated Circuits (ASIC)), where the software is loaded from a storage medium (e.g., I/O devices 406) and operated by the processor 402 in the memory 404 of the general purpose computing device 400. Thus, in one embodiment, the transaction synchronization module 405 for synchronizing executed transactions described herein with reference to the preceding Figures can be stored on a computer readable medium or carrier (e.g., RAM, magnetic or optical drive or diskette, and the like).
In one embodiment, the present invention is deployed within a Java 2 Platform, Enterprise Edition (J2EE) or Enterprise JavaBean (EJB) application environment. For example, the present invention may be deployed within any one the frameworks described by A. Leff et al., “Enterprise JavaBeans and Microsoft Transaction Server: Frameworks for Distributed Enterprise Components”, Advances in Computers, Academic Press, Vol. 54, pp. 99-152, 2001, which is incorporated herein by reference. In other embodiments, the present invention is deployed within any framework for distributed enterprise components or any object-oriented environment in which it is desirable for clients to execute transactional applications while operating over a limited server connection.
Thus, the present invention represents a significant advancement in the field of application-based transaction processing. A method and apparatus are provided that enable a client that is operating substantially autonomously to maintain a log of executed transactions. When the client re-establishes a full connection to the server, the server re-executes the logged transactions, thereby ensuring that no transactions are erroneously committed to the server database or aborted. Conflicts commonly encountered in conventional client-server synchronization processes are therefore substantially eliminated.
While foregoing is directed to the preferred embodiment of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
