Provides accessor methods for BLOBs and CLOBs, and acts as factory for LobCreator instances, to be used as sessions for creating BLOBs or CLOBs. LobCreators are typically instantiated for each statement execution or for each transaction. They are not thread-safe because they might track allocated database resources to be able to free them after execution.
Most databases/drivers should be able to work with {@link DefaultLobHandler}, which by default delegates to JDBC's direct accessor methods, avoiding java.sql.Blob
and java.sql.Clob
completely. {@link DefaultLobHandler} can also be configured to populate LOBs usingPreparedStatement.setBlob/setClob
(e.g. for PostgreSQL).
Unfortunately, Oracle 9i just accepts Blob/Clob instances created via its own proprietary BLOB/CLOB API, and additionally doesn't accept large streams for PreparedStatement's corresponding setter methods. Therefore, you need to use {@link OracleLobHandler} there, which uses Oracle's BLOB/CLOB API for both all access.The Oracle 10g JDBC driver should basically work with {@link DefaultLobHandler}as well, with some limitations in terms of LOB sizes.
Of course, you need to declare different field types for each database. In Oracle, any binary content needs to go into a BLOB, and all character content beyond 4000 bytes needs to go into a CLOB. In MySQL, there is no notion of a CLOB type but rather a LONGTEXT type that behaves like a VARCHAR. For complete portability, use a LobHandler for fields that might typically require LOBs on some database because of the field size (take Oracle's numbers as a guideline).
Summarizing the recommended options (for actual LOB fields):
streamAsLob=true
.wrapAsLob=true
.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|