When dealing with databases, you can choose to use a database only as a local data repository or as a repository that actively synchronizes with another node in the topology. In either case, if data needs to be distributed to a database, you need to balance considerations of how much data needs to be distributed and when (once only at initialization, one way from one node to another only on an infrequent basis, frequent exchange between nodes), with the storage capabilities at each node in question, and the networking requirements that would permit the exchange to take place.
In addition, if you choose synchronization, application developers should consider database organization, filtering, and conflict resolution policies. Synchronization is useful for exchanging the current state of data between nodes, where transaction boundaries or the order of state changes are not important.
When you use data synchronization, database tables are automatically created. If a database is used only for local storage and will not be synchronized with a server database, you must perform the additional step of creating the initial database.
There are a few options for creating an initial database without using database synchronization:
- Incorporate code to create the initial database within the application. The advantage of this is that the application is fully responsible for creating the database. In addition, if there is a need to rebuild the database, the code is already present. No additional steps are required by the user of the database. One disadvantage is that the code must be carried along with the application, even though it might never be used again. Another disadvantage is that the population of initial data into the database might be too large, or not appropriate to include within Java™ code. For read-only databases, this is generally not appropriate; if the data were available to populate into the database, then you probably would not need a database. Database creation code could be provided in a separate OSGi bundle that is then removed from the framework after the database has been constructed.
- Distribute the database files with the application. The database is constructed and populated outside of the client environment. The resulting database files are then distributed with the application, either in directory format or in a zip or JAR file. The advantage of this is that the code to build and populate the database runs in another environment; it does not need to be distributed with the application. This is an ideal choice for distribution of a read-only database, as the data can be distributed using CD, memory cards, or other distribution mechanisms. The disadvantages are that the distribution of the files might be more difficult than distributing code. Also, updates to the database typically require redistribution of database files.
- Distribute Data Definition Language (DDL) (a set of database statements) and require the installation application or the end user to create the database. While this overcomes some of the disadvantages of incorporating database creation code within the application, it requires that the end user be sufficiently knowledgeable to create the database, or the installation application becomes more complex. In addition, this also typically requires additional tools (such as the command-line tools DB2eCLP for DB2® Everyplace®, or ij for Apache Derby) to be present on the client or device.
Another option for database creation, and for continual update, is to use database synchronization facilities. DB2 Everyplace
and Apache Derby are both capable of synchronizing with the DB2 Everyplace
Sync Server, using the IBM
® ISync technology provided with Lotus
® Expeditor. The initial synchronization activity creates the local database tables and also populates the initial set of data. As data is updated on the client device, synchronization transfers that data to the DB2 Everyplace
Sync Server and then to other client devices that are configured to receive it. Database administrators set up the necessary subscriptions for synchronization, and can also set up filtering of data to limit the amount of data distributed to client devices.
Database application developers can use the ISync APIs provided with Lotus
Expeditor to control the synchronization process for their specific databases. This includes initiating the sync, monitoring events during the process, and managing any conflicts or errors that occur.
A simple iSync sample is available in the Rational
® Samples under Technology Samples > Lotus Expeditor
It is also important to note some differences in database application programming when using database synchronization:
Parent topic: Understanding embedded database development
- Any changes made to the local copy might appear much later in the server. Synchronization requires the application or user to initiate the sync to the sync server; the replication cycle must kick in so that changes are pushed back to the back end database server. Furthermore, the local changes can be rejected for many reasons, for example, because conflicts were found at the database server side.
- There is a latency between synchronizing changes from a client to the server and then from the server to other clients. In other words, if a change was made to a local database, these changes do not appear on another client device until the local database is synchronized successfully to the sync server. Then the sync server successfully replicates the changes to the back end database, the changes come back down the sync server for other clients; the changes show up on another client device when it successfully synchronizes.
- Database synchronization is based on row-level updates synchronized to and from the DB2 Everyplace Sync Server and the client devices. Database synchronization captures only the current state of data for synchronization. Because the database row contains only the current state of the data, there are two situations in which the application might need to provide additional capabilities. The first situation is when the ordering of updates that were applied to the database is important. The second situation is when a historical record of the changes to the rows in the database is required. In either of these situations, the application needs to provide this capability. The application can store each change in value in a separate row in the main table, or use additional tables for history purposes. Optionally, the application can use assured messaging to send the various updates to the server.
Server databases typically reside in a well-secured zone, with limited access to applications residing in other network topologies. As a result, data in the database is secured because of network location and access rights. In addition, database backup or sophisticated data management exists to protect against data loss.