Created attachment 868158 [details]
Reproducer

Description of problem:
When using Timestamp types with underlying Sybase datetime mappings, Sybase' later drivers report a warning. In the case of batch updates which impact many rows, these warnings can add up to significant memory use.

It's desirable to have Hibernate log any warnings attached to a JDBC Connection, rather than hiding them from users. Further, it is critical to clear these warnings from the statement handles to free memory.

Version-Release number of selected component (if applicable):
EAP 6.2.0 and Hibernate 4.2.7.SP1.Final

How reproducible:
Consistently

Steps to Reproduce:
1. Column map in *.hbm.xml: <property name="date" type="timestamp" column="EVENT_DATE" />
2. Underlying type in the generated table will be Sybase 'datetime'
3. Perform an insert or update (batching many inserts or update magnifies the problem)
4. In the debugger, access the statement handle and there will be warnings on it (I never found a simple way to access the handle directly in code). Alternately, stop the testcase (using the debugger or cosole read() to pause the execution - e.g. in the tearDown() metho) and extract a heap dump. In Eclipse MAT with the heap open, you can use the OQL query: 'select * from com.sybase.jdbc4.jdbc.SybPreparedStatement'. You can then sort the result by the 'Retained Heap' column and expand and see that the top of the list is the _warning member which presents the head of a list chain of SQLWarning objects. Right click _warning, select "Show Retained Set" and click Finish on the dialog to see the chained objects.

Note that I didn't find a simple way to get to the raw com.sybase.jdbc4.jdbc.SybPreparedStatement handles.

Actual results:
Memory accumulates on the underlying Sybase statement handle in the _warnings member: _warning: java.sql.SQLWarning@...

The warnings (when there are multiple due to batching) are chained together by the SQLWarning objects.

Expected results:
The warnings should be cleared at minimum and optionally logged (if logged, this must be configurable as in the case of this Sybase scenario a high volume of logging would occur).

Additional info: