PreparedStatement wrapper behavior when SQLException is thrown

Question

Environment:
weblogic8.1 sp3
IBM db2 (universal) type 4 driver
StatementCacheSize=0
Use case:
The code uses a PreparedStatement to insert let's say 60000 rows in a loop.
The method used is executeUpdate() inside the loop. Some insertion
attempts let's say 20000 are throwing duplicate primary key exception,
which is fine. When such exception occurs it is skipped and the code
continues with the next iteration inside the loop.
Problem:
Only one PreparedStatement is used in the code. Apparently the weblogic
wrapper around the PreparedStatement is using a new wrapped
PreparedStatement every time that a SQLException (in our case duplicate
primary key) occurs when calling executeUpdate(). The result is that
after ~7000 iterations in the loop (it's depend how much resources the
database was allocated for the current session) the database throws another
SQLException saying that there are no more memory resources for this
session.
Consequence:
Memory consumption is extremely high – the loop cannot finish.
I am guessing here: Every iteration in the loop that throws a SQLException
causes the wrapper to use a new PreparedStatement which means execution
of connection.prepareStatement() again – unnecessary roundtrip to the
database.
Note:
The code was tested inside the weblogic container with different
database MySQL - same behavior.
The code work without any problems outside of the weblogic container and
it uses only one object of type PreparedStatement.
Thanks,
Assen

Answer 1

Assen Sotirov wrote:
The code executes inside a POJO. Thus we can execute it as a standalone application or in EJB Session with CMP. There are only two differences:
1) how a Connection is obtained - directly using the JDBC driver (standalone) or getting it from a DataSource (inside weblogic)
2) how commit/rollback is done - directly using the Connection (standalone) or declare it in xml descriptor (inside weblogic)
Connection pool definition:
<JDBCConnectionPool
Name="upsnd3db"
DriverName="com.ibm.db2.jcc.DB2Driver"
MaxCapacity="4"
Password="{3DES}+BLABLABLABLABLA=="
Properties="user=BLABLA"
StatementCacheSize="0"
StatementCacheType="LRU"
Targets="pcs"
URL="jdbc:db2://BLABLABLABLABLA:BLA/BLA"/>
Turning the jdbc loggin on produces (IBM driver has rather verbose output, so I will truncate it):
[Connection@b0c5a] prepareStatement (insert into ...) called
[Connection@b0c5a] prepareStatement () returned PreparedStatement@b9979b
[PreparedStatement@b9979b] setString (1, 00037NHD1 ) called
[PreparedStatement@b9979b] setDate (2, 2005-09-01) called
[PreparedStatement@b9979b] setTimestamp (9, 2005-09-15 15:26:12.093) called
[PreparedStatement@b9979b] executeUpdate () called
com.ibm.db2.jcc.c.SqlException
....at com.ibm.db2.jcc.c.cl.d(cl.java:1039)
....at com.ibm.db2.jcc.c.cm.executeUpdate(cm.java:311)
....at weblogic.jdbc.wrapper.PreparedStatement.executeUpdate(PreparedStatement.java:115)
BEGIN TRACE_DIAGNOSTICS
com.ibm.db2.jcc.c.SqlException:
DB2 SQL error:
SQLCODE: -803,
SQLSTATE: 23505,
[Connection@b0c5a] prepareStatement (insert into ...) called
[Connection@b0c5a] prepareStatement () returned PreparedStatement@9830bc
[PreparedStatement@9830bc] setString (1, 000759BA7 ) called
Notice that the StatementCacheSize is 0 and also a new PreparedStatement is allocated and used after the SQLException is thrown. This contradict to your statement:
I see, and I see something in the code. I have attached a
patch to tey (get it ahead of the weblogic.jar in the
server classspath).
thanks
Joe
I am saying that for a zero-cache setup, the serverside statement wrapper
won't change in any loop, and neither will the DBMS driver statement it
wraps, regardless of any exceptions during execute() calls.Thanks,
Assen