Java Reference
In-Depth Information
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
.
3.5.1
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.
3.5.2
SQL injection
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.
