Reputation: 1022
I have created an implementation of JDBC driver, which in turn manages connection to two DB( for eg, postgres and mysql). For all JDBC operation these connections are maintained, based on certain logic request are catered. My questions are
Upvotes: 0
Views: 1107
Reputation: 718798
I don't think this is a good approach.
The fundamental issue is that the different database backends have differences that are difficult to "paper over" with a unified JDBC driver. The most obvious issue is that there are (significant) difference between the different dialects of SQL ... including differences in the supported data types. It is difficult (to impossible) to hide these differences is your application level code is using the JDBC APIs as they are normally used.
There are two approaches that work better (IMO).
A typical object-relational mapping (such as hibernate) will provide adapters for multiple database back ends that deal with the differences. They do this by expressing your queries in a more abstract fashion, and turning the queries into database-specific SQL behind the scenes.
Deal with the database-specific aspects yourself ... in database adapter code that is specific to your application. This entails building your own framework for generating or templatizing your queries to deal with the dialect differences. Then you use the existing database-specific JDBC drivers, passing them the right kind of SQL.
FWIW - I don't see why memory management is a particular issue with your proposal.
Upvotes: 2
Reputation: 24885
1) Usually this kind of thing is managed by a DAO (Data Access Object, a layer that manages persistence). Making it a JDBC driver just forces you to follow certain restrictions that make it harder to code (I understand your driver will not be very reusable).
2) Depends of how well you coded it. Without more details it is hard to tell, but there is no reason why you had to have memory management issues.
Upvotes: 3