You have only one more element of JDBC to cover—distributed transactions. All database access you have dealt with so far involves transactions against a single database. In this environment, your DBMS manages the details of each transaction. This support is good enough for most database applications. As companies move increasingly towards an enterprise model of systems development, however, the need for supporting transactions against multiple databases grows. Where single data source transactions are the rule today, they will likely prove the exception in business computing in the future.
Distributed transactions are transactions that span two or more data sources. For example, you may have an Informix data source containing your corporate digital media assets and an Oracle database holding your corporate data. When you delete product information for an obsolete product line stored in the Oracle database, you need to know that the commercials and web images stored in Informix database have been deleted as well. Without support for distributed transactions, you are forced to handle the delete in two separate transactions: one against Oracle and the other against Informix. If the commit against Oracle succeeds but the Informix commit fails, you end up with inconsistent data.
Of course, you may simply avoid the issue by selecting either Oracle or Informix to store all of your corporate data. If you choose a nice supercomputer with terabytes of hard disk space ...