Database Management Systems - Occasionally Connected Applications
In the last week I have been looking at a couple of new development tools that support the occasionally connected user. I am particularly interested in these - because I am one of those users. When I am in my car, or on a plane, I still want to be able to do my work. But if I am using applications that require connectivity, I may be in trouble (I do have a portable router and cellular communication for my car - but I am not always in range).
Two of hese tools are, Apollo, and Google Gears. Both provide the ability to work with a local database on the client on the client machine when you are not connected. But neither address the design patterns required to manage synchronization between the client and the server.
A couple of examples of the design patterns are:
- An RSS feed client - that just views the current entries. When you next sync, overwrite any data on the client with the current data from the server.
- A data entry application - that allows users to add or edit data. But for a given data element, there is only one authorized writer/updater. When you next sync, overwrite any data on the server with the new client data. There are still potential conflicts - for instance if the user syncs from a different session (typically machine) and the first machine hadn’t yet done its sync. Any individual sync without apparent conflict is allowed. But updating an already deleted row will obviously be an issue.
The examples get more complicated - and have to be thought through carefully for a given application. These tools are making it too easy for people to walk in to synchronization issues in application implementation.
Jim on June 4th 2007 in Gears, Apollo, GDD07, Database Management Systems
One Response to “Database Management Systems - Occasionally Connected Applications”
Leave a Reply
You must be logged in to post a comment.
mpanttaja responded on 05 Jun 2007 at 9:17 pm #
I think that this is a case of a new technology path running up against an older, fairly well-known problem. But it is not necessarily a straight-forward set of solutions and I think it will be interesting to see if the new network architectures lead to easier solutions than we were able to build in the 90’s. I think it would be interesting to create a set of “distributed dataspace” attributes and use them to define and clarify an orthogonal set of use cases. This is all key, of course, to how much the application has to be redesigned and rebuilt to meet these requirements.
What else needs to go on this list?
Data Ownership (the obvious) Identity of the primary datastore of record
Which applications can change data?
Can you control single threading of access?
Is data element ownership isolated?
Band-width criteria vs data sizing Is the relative bandwidth generous enough to enable simple over-right replication solutions?
Or do we need to be stingy with our messages and keep ownership and time stamps on everything.
Recovery requirements
Security requirements
Changing cross table validations and references
Etc.
From combinations of such factors perhaps we can build use-cases, design patterns, and clear solution patterns.
As you point out, it’s one thing to say you can enable an application to work offline and on the desktop, but it’s another if the application is about persistant data. But it is also an interesting design challenge—which is always fun.