So far we've discussed simple local database access from Java using JDBC, and various approaches for connecting Java agents to remote databases. Some simple extensions to these approaches allow you to connect a Java agent to multiple remote databases, and create some interesting possibilities for applications in data analysis and management.
A feature of JDBC that should be obvious from earlier sections is that it insulates the application from the proprietary details of the database. So assuming that we've encapsulated the data-access tier of our application well, and that we have local JDBC drivers that can access each database server, we can easily distribute our data across multiple database servers and still pull the data together into a single set of data objects simply by using multiple Connection objects.
As an example, suppose that the tables shown in Figure 7-3 are stored in two separate databases: all tasks and time constraints on tasks are stored in a database named "sequence" on server "data1," while resource and resource assignment data is stored in a database named "schedule" on server "data2." Our JDBC-enabled data objects now simply need access to Connections to each of these databases, assuming that the tables in the separate databases are defined the same way they were in the single database. We can modify our DatabaseItem class to contain two Connection objects, as shown in Example 7-13.
abstract class DatabaseItem {
static Connection seqConn;
static Connection schedConn;
boolean valid;
public boolean isValid() { return valid; }
protected abstract boolean updateToDbase();
protected abstract boolean updateFromDbase();
}
Our application or applet would then initialize these database connections to access the correct DBMS servers:
Class.forName("my.custom.dbase.Driver");
SchedDbaseItem.seqConn =
DriverManager.getConnection("jdbc:mydriver:data1:sequence",
"myuser", "mypassword");
SchedDbaseItem.schedConn =
DriverManager.getConnection("jdbc:mydriver:data2:schedule",
"myuser", "mypassword");
Finally, each of our data objects would invoke the necessary Connection object to access its data. With these two database connections available to all DatabaseItems in the system, the SchedResource.updateToDbase() method would access the "schedule" database for its data,
Statement s = DatabaseItem.schedConn.createStatement();
int numr = s.executeUpdate("UPDATE resource SET name = " + name
+ ", type = " + type + ", size = " + size
+ " WHERE rid = " + rid);
while the SchedTask.updateToDbase() method would access the "sequence" database:
Statement s = SchedDbaseItem.dbConn.createStatement();
int numr = s.executeUpdate("UPDATE task SET type = "
+ type + ", size = " + size
+ " WHERE tid = " + tid);
The ease with which data in multiple databases is accessible using JDBC can be a bit deceiving, however. Many other issues come to bear on a system that is accessing or updating data from multiple remote data servers--one is the issue of maintaining data integrity between the databases. In our example, we've put ourselves in a tricky spot by requiring that the task and resource identifiers must be synchronized between the two sets of data tables. If we can guarantee that our Java data objects are the only agents that update data in these tables, it's simply a matter of building the right logic into our classes to ensure that identifiers are kept synchronized between the data servers. If not, then we should really look into other options, such as using our own secondary tables to maintain cross-references between the data servers, linking the two databases at the relational level (if the network connectivity between them allows us to do this), or even merging the two databases back into a single data server.
 |  |  |
| 7.2. Remote Database Applications |  | 8. Bandwidth-Limited Systems |
Copyright © 2001 O'Reilly & Associates. All rights reserved.
| This HTML Help has been published using the chm2web software. |