Sun's biggest contribution to JDBC is not in the implementations but in the
interfaces. Vendors are required to implement connectivity to their database
according to the interfaces defined by JDBC . If they do not, developers are
unlikely to use them, because (in the Java world at least) vendor lock-in is consid-
ered an anti-pattern to be avoided.
The JDBC API borrows many concepts from Microsoft's ODBC API , and has
been a core component of Java since version 1.1, which was released in 1997. In
1999, version 2 of the JDBC API was released, and in 2002, version 3 was released.
Version 4 is being designed now as part of JCP-221 .
The i BATIS framework currently requires at least version 2 of the API, but is
compatible with version 3 as well.
With that brief introduction to JDBC , let's take a look at a few issues you need
to be aware of when using it without i BATIS .
Releasing JDBC resources
When using JDBC , it is easy to acquire resources and forget to properly release
them. While the garbage collection process may eventually release them, this can
take time and is not guaranteed. If these objects do not get released, the application
eventually runs out of available resources and crashes. The i BATIS framework helps
to manage these resources by removing the burden of managing them from the
application developer. Instead of worrying about what resources are being allo-
cated and released, developers can focus on the data they need and how to get it.
However, developers can still manage these resources manually if they so choose.
Another common problem (more prevalent in web applications) is that of SQL
injection , which is a way of using an application to execute SQL in a way that was
not intended by the developer. If an application uses string concatenation to
build SQL statements without properly escaping the parameters, a malicious user
can pass in parameters that will change the query. Take the example of a query
like select * from product where id = 5 . If the 5 comes directly from the user, and
is concatenated to select * from product where id = then the user could pass in 5
or 1=1 to change the meaning of the SQL statement. It would be even worse if the
user passed in 5; delete from orders , which would dutifully select the one
record, then clean out your orders table. With flexibility comes risk, and
therefore using i BATIS incorrectly can still expose your application to a SQL
injection attack. However, i BATIS makes it easier to protect the application by
always using PreparedStatement s that are not susceptible to this type of attack.