Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CardSync Synchronization

Revision as of 08:52, 10 July 2009 by Ayuhimenko.parityinc.net (Talk | contribs) (Problems)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg


Problems

There are few situations when client should synchronize local icard store with server:

  • client app worked off-line and user made some changes (for example, user could update p-cards traveling by plane), so client has list of changes (array of CommandTO) which should be passed to server;
  • client app determinate that client RootRevision less then server RootRevision ( for example, user could use client app on other device(laptop/iphone/etc) ), so client app should load changes from server.

Strategy

  1. Client app should compare local RootRevision with server RootRevision. If they're not equals, i.e. client RootRevision may less than server, that client must load changes from server.
  2. Only after loading changes from server, and If client app has list of local changes, client should upload them to server.

Transfer objects

CardSync Synchronization TOs.png

CommandTO

Command transfer object. Encapsulate commands in transfer objects. Please, see "Command" design pattern.

  • String id - Represents command id, Client should use it it for processing command executed status @see CmdExecStatusTO.
  • String name - Represents operation/command name. It must be one of the following constants:Add/Update/Delete.
  • String resourceType - Represents resource type. It might be "PCard","MCard","CardHistory","UserProfile" etc.
  • String resourceId - Represents server resource identifier. @see BaseTO#id
  • BaseTO resource - Represents resource.

CmdExecStatusTO

Represents command executed status TO.

  • String commandId - Represents command id. @see CommandTO#id
  • String statusCode - Represent status code of executed command on server. It may be '0' or error code.
  • String statusMessage - Represent status message of executed command on server. it may be used for returning error message.

From server to client

Client have to load changes from server passing client "RootRevision" by using:

  • REST - GET /CommandLog request;
  • JAX-WS - getCommandLog request.

These methods return array of CommandTO, which client have to process.

From client to server

Client have to upload local changes to server by using:

  • Rest - PUT /CommandLog request;
  • JAX-WS - execCommands request.

These methods return array of CmdExecStatusTO. Client have to check CmdExecStatusTO.statusCode. if CmdExecStatusTO.statusCode is not "0" (server couldn't apply changes), client should update resource from server and reject local changes or ask user about.

Problems

Client passes list of command to server, however server executes each command in separate transaction. Server doesn't use transaction manager, in other world each component manage local transaction itself. So if one client app uploads changes to server and the other client app update something on server in the same time, some changes may be lost between clients.

For example, if user start client app on laptop (this client start synchronization (uploading changes to server)), and start working with iphone client (this client changes data), that some changes may not be synchronized between clients.

For avoiding it, client app should check the following conditions:

  • if after uploading changes "new server RootRevision" not equals "old server RootRevision" plus number of correct executed command, client should load changes between "old server RootRevision" and "new server RootRevision" again;
  • if after invoking server method server RootRevision was increased more than 1, client should load changes between "old server RootRevision" and "new server RootRevision".

However, the best way is re-implemented server for supporting high level transaction with JTA.

Back to the top