still require dependencies on the third-party
Figure 12.1 depicts this. The arrows can be
read as “depends on,” or at least “knows about.”
As stated earlier, iBATIS supports plugga-
ble component design for a number of its fea-
tures. But what exactly does that mean?
Generally a plug-in is an extension to an appli-
cation or framework that adds new function-
ality that wasn't there before, or that replaces
existing functionality with something differ-
ent. For the most part, iBATIS extension
involves replacing existing functionality.
iBATIS is designed in layers, and it is within each layer that iBATIS may provide
a plug-point into which you can inject your own functionality. Table 12.1 describes
the iBATIS layers, and summarizes the extensibility at a high level.
Figure 12.1 Example of a pluggable
Layered extension summary
TypeHandlerCallback Implement your own type handling logic to deal with nonstandard
databases, drivers, and/or data types.
Implement your own CacheController for your own cache code
or to provide support for a third-party caching solution.
Supply any standard JDBC DataSource implementation.
Implement a custom transaction manager to work best with your
The next sections describe each of these in more detail, beginning with the most
common type of extension: TypeHandlerCallback .
12.2 Working with custom type handlers
As much as we'd all like relational database management systems to be standard,
unfortunately they just aren't. They all tend to implement their own SQL exten-
sions, as well as their own data types. Although more common data types like
binary large objects ( BLOB s) and character large objects ( CLOB s) are supported
by most relational databases, they are usually handled differently by each driver.