We are using Lukasz's "Updated Clobs handling for Oracle and Hibernate" solution and experiencing a problem.

The table which contains the CLOB is working fine. However, we are using this table cascaded from another table and it randomly fails to insert to the parent table.

Let me illustrate what I mean...
<hibernate-mapping package="pallas.crossroads.data.bean">
<class name="MessageQueue" table="MESSAGE_QUEUE">
<many-to-one
name="message"
class="ClobData"
not-null="false"
cascade="all"
>
<column name="MESSAGE"/>
</many-to-one>
</class>

<hibernate-mapping package="pallas.crossroads.data.bean">
<class name="ClobData" table="CLOB_DATA">
<id
column="CLOB_DATA_ID"
name="id"
type="integer"
>
<generator class="sequence">
<param name="sequence">CLOB_DATA_ID</param>
</generator>
</id>
<property
column="CLOB_DATA"
name="clobData"
not-null="true"
type="com.pallas.hibernate.clob.OracleClobType"
/>
</class>
</hibernate-mapping>

So, a MessageQueue object has a field which refers to a ClobData object, with a cascade type of "all". (There are actually a couple more fields in MessageQueue, deleted for clarity, but only strings and integers). OracleClobType is just our name for StringClobType.

I execute the following code:
tx = hibernateSession.beginTransaction();
MessageQueue hibernateMessageQueue = new MessageQueue();
ClobData messageClob = new ClobData();
messageClob.setClobData(message);
hibernateMessageQueue.setMessage(messageClob);
MessageQueueDAO dao = MessageQueueDAO.getInstance();
dao.save(hibernateMessageQueue, hibernateSession);
tx.commit();

So, this should insert two records, ClobData (cascaded) and MessageQueue. ClobData never fails to insert. However, the MessageQueue record seems to succeed sometimes and fail at other times. This is true even when the actual message string is identical between runs and definately much less than the 4000 character limit.

Do you know what might be causing this problem? If I change the line
hibernateMessageQueue.setMessage(messageClob);
to
hibernateMessageQueue.setMessage(null);
then the MessageQueue will always save correctly to the database.
This leads me to believe that it is some interaction of the cascading with your CLOB solution that might be causing the difficulty.

Thanks for any assistance that anyone can offer regarding this problem!

We are using the most recent stable version of Hibernate (2.1.7).

Our problem has been resolved, and it was due to our own deployment problem, nothing to do with Hibernate, Oracle drivers, or Lukasz's proposed workaround.

Many pardons. However, to make it up to the community, here are my notes on the DataDirect Oracle drivers.

Since we suspected a problem with the StringClobType workaround for the buggy Oracle drivers, I downloaded a 15-day trial version of the DataDirect Oracle drivers to use instead.

Swapping the new driver in was pretty easy, but here are some notes to help out anyone else who wants to do it.

in hibernate.cfg.xml, I replaced this:
<property name="hibernate.connection.url">
jdbc:oracle:thin:@perseus:1521:xroads
</property>
<property name="hibernate.connection.driver_class">
oracle.jdbc.driver.OracleDriver
</property>

with this:
<property name="hibernate.connection.url">
jdbc:datadirect:oracle://perseus:1521;SID=xroads
</property>
<property name="hibernate.connection.driver_class">
com.ddtek.jdbc.oracle.OracleDriver
</property>


In our HBM file, I replaced this:
<property
column="CLOB_DATA"
name="clobData"
not-null="true"
type="com.pallas.hibernate.clob.OracleClobType"
/>

with this:
<property
column="CLOB_DATA"
name="clobData"
not-null="true"
type="text"
/>

You can remove the Interceptor, although leaving it in place does not cause any errors. It will just cease to have anything to intercept.

After fixing our deployment issue, I found that the StringClobType workaround and the DataDirect driver both appear to work quite well at resolving the CLOB issues that occur with the stock Oracle driver. User either solution that you prefer. StringClobType is free, so I'll be going with that. I am also hoping that in future versions of Hibernate this fix will be built-in, so that we can all avoid the pain and suffering of Oracle CLOB bugginess.