I have a requirement to write a daemon based java process (Not web based) that will connect to an Oracle 10G database, read some data from it and then connect to a SQL Server database and write the data to a table.
Sounds simple enough but i have a couple of queries about this.
i will need to have two jdbc drivers, i.e. one for connecting to the Oracle database and the other for connecting to the sql server database. The sql server jdbc driver is the jtds jdbc driver (http://jtds.sourceforge.net/) and for Oracle i will be using the standard oracle jdbc driver. Am i likely to come across any problems with both drivers available in the classpath together?
My guess is that all i need is a ConnectionManager class to manage the connections and a client DAO class that would call the relevant method to get the connection it needs depending on whether it is reading from Oracle or writing to SQL Server. Is this a reasonable approach or is there a better design/pattern for this?
Ok i have tried to put together a quick design solution. See image below
The problem i think i am having is how to commit. Here is the flow of processing
InvoiceBD commits the Oracle connection. InvoiceBD commits the SQL Server connection.
Or if something goes wrong both connection objects are rolled back.
Does that sound about right?
Thanks
Am i likely to come across any problems with both drivers available in the classpath together?
Unlikely. The DriverManager.getConnection
method actually delegates the construction of the connection to all drivers registered with it. Only drivers that recognize the protocols in the JDBC URL will return the connection. The JDBC specification states:
When the
DriverManager
is trying to establish a connection, it calls that driver’s connect method and passes the driver the URL. If theDriver
implementation understands the URL, it will return aConnection
object; otherwise it returnsnull
....
The format of a JDBC URL is :
jdbc:<subprotocol>:<subname>
In the case of both jTDS and the Oracle (thin) driver, the protocol formats are different, and hence, you would never experience a problem. However, remember not to place more than one version of the same driver.
Is this a reasonable approach or is there a better design/pattern for this?
You are looking for a DataSource
. DataSources would have been availble in a Java EE environment, and not in Java SE applications. You can however, build your own DataSource or a similar class; you don't need to implement the DataSource interface itself, but you could do something similar. In your context, the ConnectionManager
class of yours will assume the role of the DataSource by possibly accepting a parameter that distinguishes which database to connect to; you could think about using a connection pool in case you need one (unlikely if you need only one connection to the database).
You could also adopt @duffymo's approach of building DAO classes, although it is better suited for a situation where the SQL queries are different.