Connection Pool Issues in AIX

muthuku...@hotmail.com

unread,

Jun 21, 2007, 7:51:29 PM6/21/07

to

Hi,

We are getting the following execption

Environment:
------------
AIX - WAS Express 6.1.0.7 (WAS 6.1 applied update pack 6.1.0.7)
Exception:
----------
com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: Cannot call 'cleanup' on a ManagedConnection while it is still in a transaction

Exception occurred while trying to close the connection. This code runs fine with Solaris, Linux & windows Operating system.

Solutions already tried:
------------------------
Initially it was not working Windows operating system, after increasing unused (1800 to 5800) and aged (1800 to 5800) connection properties, it started working with windows operating system too.

We tried with various options with unused, Aged, Max connection, Min connection & reap time properties (Changing values from 0 to maximum values)

But it is not working with AIX environment alone. We have also increased the statement cache size.

Are we missing any setting? Or is there any known issues with WAS 6.1.0.7 with AIX operation system. This code works fine with prior version of WAS 6.0 Express and application server.

Can you help us in this issue?

Brian S Paskin

unread,

Jun 22, 2007, 3:21:03 AM6/22/07

to

Hi, Which Database are your using?

muthuku...@hotmail.com

unread,

Jun 22, 2007, 9:51:16 AM6/22/07

to

Sorry, I missed the important information.

It's Oracle 10G, we are using the ojdbc14.jar (10.2.0.2.0)

Brian S Paskin

unread,

Jun 22, 2007, 10:05:39 AM6/22/07

to

Hi, you are probably receiving more than this error in the log, could you please post the full error?

Brian

muthuku...@hotmail.com

unread,

Jun 22, 2007, 11:39:13 AM6/22/07

to

Here is a brief description about the issue. In our code we are trying to insert bulk data by setting auto commit as false, the same code work fine with fewer amounts of data.

As I have already mentioned we are not at all getting this issues in Solaris & Linux environment and in Windows if we increase the ?unusedTimeout & agedTimeout? to 5800 we are not getting this issue. We are getting this issues only AIX now.

In AIX, when we ran the same code with older version of the oracle driver (9.0.2.0.0), it?s working fine, but we cant revert back to old version of the driver.

Following is the error we got in SystemErr.log file:
--------------------------------------------------------------

[6/18/07 16:33:18:350 EDT] 00000021 SystemErr R Exception in thread "Thread-45" java.lang.AbstractMethodError: sun/util/calendar/AbstractCalendar.getFixedDate(Lsun/util/calendar/CalendarDate;)J
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at sun.util.calendar.AbstractCalendar.getTime(AbstractCalendar.java:186)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at sun.util.calendar.ZoneInfo.getOffset(ZoneInfo.java:391)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at oracle.jdbc.driver.DateCommonBinder.zoneOffset(OraclePreparedStatement.java:15472)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at oracle.jdbc.driver.DateCommonBinder.setOracleCYMD(OraclePreparedStatement.java:15610)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at oracle.jdbc.driver.DateBinder.bind(OraclePreparedStatement.java:15690)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.setupBindBuffers(OraclePreparedStatement.java:2897)
[6/18/07 16:33:18:351 EDT] 00000021 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.processCompletedBindRow(OraclePreparedStatement.java:2182)
[6/18/07 16:33:18:352 EDT] 00000021 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3311)
[6/18/07 16:33:18:352 EDT] 00000021 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3400)
[6/18/07 16:33:18:352 EDT] 00000021 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate(WSJdbcPreparedStatement.java:948)
[6/18/07 16:33:18:352 EDT] 00000021 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:615)
[6/18/07 16:33:18:352 EDT] 00000021 SystemErr R at com.taxware.twe.loaddata.persistor.LoadDataDefaultDAO.updateApplyStatus(LoadDataDefaultDAO.java:658)

Following is the error we got in SystemOut.log file:
--------------------------------------------------------------
******** E J2CA0081E: Method cleanup failed while trying to execute method cleanup on ManagedConnection WSRdbManagedConnectionImpl@78ce78ce from resource LoadDataDS. Caught exception: com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: Cannot call 'cleanup' on a ManagedConnection while it is still in a transaction..
at com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:236)
at com.ibm.ws.rsadapter.exceptions.DataStoreAdapterException.<init>(DataStoreAdapterException.java:185)
at com.ibm.ws.rsadapter.AdapterUtil.createDataStoreAdapterException(AdapterUtil.java:305)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(WSRdbManagedConnectionImpl.java:3523)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanup(WSRdbManagedConnectionImpl.java:3150)
at com.ibm.ejs.j2c.MCWrapper.cleanup(MCWrapper.java:1417)
at com.ibm.ejs.j2c.FreePool.returnToFreePool(FreePool.java:480)
at com.ibm.ejs.j2c.PoolManager.release(PoolManager.java:1615)
at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:2246)
at com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEventListener.java:288)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionClosedEvent(WSRdbManagedConnectionImpl.java:1527)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnection.java:770)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:180)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:139)

[6/21/07 17:23:55:136 EDT] 00000024 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl open FFDC0009I: FFDC opened incident stream file /develop/zdevm/IBM617/WebSphere/AppServer/profiles/Twe65_20/logs/ffdc/server1_60b660b6_07.06.21_17.23.55_1.txt
[6/21/07 17:23:55:149 EDT] 00000024 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC closed incident stream file /develop/zdevm/IBM617/WebSphere/AppServer/profiles/Twe65_20/logs/ffdc/server1_60b660b6_07.06.21_17.23.55_1.txt
[6/21/07 17:23:55:188 EDT] 00000024 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl open FFDC0009I: FFDC opened incident stream file /develop/zdevm/IBM617/WebSphere/AppServer/profiles/Twe65_20/logs/ffdc/server1_60b660b6_07.06.21_17.23.55_2.txt
[6/21/07 17:23:55:210 EDT] 00000024 ServiceLogger I com.ibm.ws.ffdc.IncidentStreamImpl resetIncidentStream FFDC0010I: FFDC closed incident stream file /develop/zdevm/IBM617/WebSphere/AppServer/profiles/Twe65_20/logs/ffdc/server1_60b660b6_07.06.21_17.23.55_2.txt
[6/21/07 17:23:55:219 EDT] 00000024 MCWrapper E J2CA0081E: Method destroy failed while trying to execute method destroy on ManagedConnection WSRdbManagedConnectionImpl@78ce78ce from resource No longer available. Caught exception: java.lang.NullPointerException
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.cleanupTransactions(WSRdbManagedConnectionImpl.java:3501)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.destroy(WSRdbManagedConnectionImpl.java:2928)
at com.ibm.ejs.j2c.MCWrapper.destroy(MCWrapper.java:1728)
at com.ibm.ejs.j2c.FreePool.returnToFreePool(FreePool.java:506)
at com.ibm.ejs.j2c.PoolManager.release(PoolManager.java:1615)
at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:2246)
at com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEventListener.java:288)
at com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl.processConnectionClosedEvent(WSRdbManagedConnectionImpl.java:1527)
at com.ibm.ws.rsadapter.jdbc.WSJdbcConnection.closeWrapper(WSJdbcConnection.java:770)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:180)
at com.ibm.ws.rsadapter.jdbc.WSJdbcObject.close(WSJdbcObject.java:139)

Brian S Paskin

unread,

Jun 22, 2007, 12:25:29 PM6/22/07

to

Hi, What is the time difference between committing the records? The reason I ask, is that you mentioned setting the agedTimeout and unusedTimeout. The transaction needs to be committed before cleaning up.

Also, you may need to change some settings in Oracle:
http://www-1.ibm.com/support/docview.wss?uid=swg21215890

muthuku...@hotmail.com

unread,

Jun 22, 2007, 12:57:36 PM6/22/07

to

Thanks for your immediate response.

We read data from various XML and insert them into tables. The same code is working fine if the size of the XML is less, but if it is huge it fails.

We are getting the failure with in 5 min from starting the operation, following is the setting for connection pool.

connectionTimeout="1800" maxConnections="125" minConnections="25" reapTime="180" unusedTimeout="1800" agedTimeout="1800" purgePolicy="FailingConnectionOnly"

By increasing the unusedTimeout & agedTimeout it works in Windows, but not in AIX.

Please let us know if you need further information.

Brian S Paskin

unread,

Jun 22, 2007, 1:07:42 PM6/22/07

to

Hi, I still believe the problem lies within Oracle and not WebSphere or AIX. Please follow the link I provided previously and update the necessary settings for Oracle.

BTW... have a transaction open for 5 minutes is quite long. Do you really want it to run that long?

Brian

Peter Bennett

unread,

Jun 22, 2007, 2:45:47 PM6/22/07

to

It's likely to be either the Oracle listener timing the transaction out, or
the transaction service within WebSphere.
You tend to get a more obvious error message when it's WebSphere doing it
though. WebSphere doesn't abort the transaction when it springs the
timeout, but I suspect that Oracle can get impatient eventually. Might be
worth checking the Oracle docs for timeout settings, but I seem to remember
that the shortest one is in the listener.

Oh, and try parsing the XML before you begin the transaction perhaps, unless
you need it to be an atomic action, such as getting it in one big chunk of
an MQ queue.
XML parsing is (relatively) slow and should probably be avoided during the
lifetime of a transaction.

Peter Bennett
Distributed Systems Professional Services.

"Brian S Paskin" <bpa...@us.ibm.com> wrote in message
news:834356867.1182532158...@ltsgwas009.sby.ibm.com...

Paul Ilechko

unread,

Jun 22, 2007, 6:50:04 PM6/22/07

to

muthuku...@hotmail.com wrote:
> Thanks for your immediate response.
>
> We read data from various XML and insert them into tables. The same
> code is working fine if the size of the XML is less, but if it is
> huge it fails.
>
> We are getting the failure with in 5 min from starting the operation,
> following is the setting for connection pool.
>

You should not have 5 minute transactions. You need to restructure your
application to behave in a more sensible manner. For example, do all of
your XML parsing *before* starting the transaction.

muthuku...@hotmail.com

unread,

Jun 25, 2007, 10:36:41 AM6/25/07

to

Thanks for all your comments.

We tried increasing the transaction timeout, but even that was not working.

Also I was wrong in saying that the whole transaction was running for 5 min. actually the whole operation takes 5 min and the individual transaction will run in less than a min.

We are facing this issue on AIX alone.

We tried to set the ?reapTime? to ?0? to block the pool maintenance thread from running, but even after that we are getting the following error

?Method cleanup failed while trying to execute method cleanup on ManagedConnection WSRdbManagedConnectionImpl@10bc10bc from resource LoadDataDS. Caught exception: com.ibm.ws.exception.WsException: DSRA0080E: An exception was received by the Data Store Adapter. See original exception message: Cannot call 'cleanup' on a ManagedConnection while it is still in a transaction..?

Which clearly says that the pool maintenance thread is running and trying to clear the pool, Is this a know bug with WAS?

Paul Ilechko

unread,

Jun 25, 2007, 11:00:44 AM6/25/07

to

muthuku...@hotmail.com wrote:
> Thanks for all your comments.
>
> We tried increasing the transaction timeout, but even that was not
> working.
>
> Also I was wrong in saying that the whole transaction was running for
> 5 min. actually the whole operation takes 5 min and the individual
> transaction will run in less than a min.

That's still way too long.

>
> We are facing this issue on AIX alone.
>
> We tried to set the ?reapTime? to ?0? to block the pool maintenance
> thread from running, but even after that we are getting the following
> error
>
> ?Method cleanup failed while trying to execute method cleanup on
> ManagedConnection WSRdbManagedConnectionImpl@10bc10bc from resource
> LoadDataDS. Caught exception: com.ibm.ws.exception.WsException:
> DSRA0080E: An exception was received by the Data Store Adapter. See
> original exception message: Cannot call 'cleanup' on a
> ManagedConnection while it is still in a transaction..?
>
> Which clearly says that the pool maintenance thread is running and
> trying to clear the pool, Is this a know bug with WAS?
>

I don't know, but if you want to find out you need to open a PMR with
IBM Support.

Ben_

unread,

Jun 25, 2007, 12:03:49 PM6/25/07

to

>> actually the whole operation takes 5 min and the individual
>> transaction will run in less than a min.
>
> That's still way too long.
>

What would be a suitable value ?

Brian S Paskin

unread,

Jun 25, 2007, 12:14:23 PM6/25/07

to

Hi, the problem is that the error says that the transaction has not ended. It appears that there is an error in the code since the transaction has not ended before the cleanup.

For me, it would depend on what is being done. The problem of a long running transaction is that it could lock other resources for a long period of time and slow down processing.

Brian

Paul Ilechko

unread,

Jun 25, 2007, 1:30:00 PM6/25/07

to

Well, that depends, doesn't it? The real problem with long running
transactions is that they are holding database locks, so you get
contention. If you have ten users, that might not be an issue. If no-one
ever tries to get the same record, that might not be an issue. Usually,
though, it's a problem.

chris.k...@taxware.com

unread,

Jun 26, 2007, 10:45:47 AM6/26/07

to

We noticed a strange thing, the version of the java that comes bundled with websphere 6.1 for AIX says

?IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20061001 (JIT enabled)?

But for the older version of websphere 6.0 it says

?Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX 5L for PowerPC?

Is this causing the problem?

We are also getting the following error, which might be the original cause of the failure of our application.

[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R Exception in thread "Thread-45" java.lang.AbstractMethodError: sun/util/calendar/AbstractCalendar.getFixedDate(Lsun/util/calendar/CalendarDate;)J
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at sun.util.calendar.AbstractCalendar.getTime(AbstractCalendar.java:186)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at sun.util.calendar.ZoneInfo.getOffset(ZoneInfo.java:391)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.DateCommonBinder.zoneOffset(OraclePreparedStatement.java:15472)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.DateCommonBinder.setOracleCYMD(OraclePreparedStatement.java:15610)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.DateBinder.bind(OraclePreparedStatement.java:15690)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.setupBindBuffers(OraclePreparedStatement.java:2897)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.processCompletedBindRow(OraclePreparedStatement.java:2182)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3311)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3400)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate(WSJdbcPreparedStatement.java:948)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:615)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.test.loaddata.persistor.LoadDataDefaultDAO.updateApplyStatus(LoadDataDefaultDAO.java:658)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.test.loaddata.persistor.ManifestProcessor.process(ManifestProcessor.java:96)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.test.facade.impl.ThreadLoadDataFacade.apply(ThreadLoadDataFacade.java:72)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at java.lang.reflect.Method.invoke(Method.java:615)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:281)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:187)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:154)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:107)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at $Proxy22.apply(Unknown Source)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.test.loaddata.persistor.DataApplier.apply(DataApplier.java:100)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at com.test.loaddata.persistor.DataApplier.run(DataApplier.java:139)
[6/25/07 16:40:42:381 EDT] 00000033 SystemErr R at java.lang.Thread.run(Thread.java:799)

Doug Breaux

unread,

Jun 26, 2007, 11:11:23 AM6/26/07

to

I don't know about "strange", but WAS 6.1 does use Java 5, whereas 6.0 used
Java 1.4.

chris.k...@taxware.com wrote:
> We noticed a strange thing, the version of the java that comes bundled with websphere 6.1 for AIX says
>
> ?IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 AIX ppc-32 j9vmap3223-20061001 (JIT enabled)?
>
> But for the older version of websphere 6.0 it says
>
> ?Classic VM (build 1.4.2, J2RE 1.4.2 IBM AIX 5L for PowerPC?
>
> Is this causing the problem?
>

--
Doug

Ben_

unread,

Jun 26, 2007, 11:31:13 AM6/26/07

to

How does this relate to the current discussion ?

muthuku...@hotmail.com

unread,

Jun 27, 2007, 11:45:09 AM6/27/07

to

We upgraded to webshere 6.1-9fix pack, after that, the connection pool issue is gone and only the following failure is thrown in the SysteErr.log

[6/27/07 11:27:57:641 EDT] 00000024 SystemErr R Exception in thread "Thread-45" java.lang.AbstractMethodError: sun/util/calendar/AbstractCalendar.getFixedDate(Lsun/util/calendar/CalendarDate;)J
[6/27/07 11:27:57:642 EDT] 00000024 SystemErr R at sun.util.calendar.AbstractCalendar.getTime(AbstractCalendar.java:186)
[6/27/07 11:27:57:642 EDT] 00000024 SystemErr R at sun.util.calendar.ZoneInfo.getOffset(ZoneInfo.java:391)
[6/27/07 11:27:57:642 EDT] 00000024 SystemErr R at oracle.jdbc.driver.DateCommonBinder.zoneOffset(OraclePreparedStatement.java:15494)
[6/27/07 11:27:57:642 EDT] 00000024 SystemErr R at oracle.jdbc.driver.DateCommonBinder.setOracleCYMD(OraclePreparedStatement.java:15632)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at oracle.jdbc.driver.DateBinder.bind(OraclePreparedStatement.java:15712)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.setupBindBuffers(OraclePreparedStatement.java:2911)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.processCompletedBindRow(OraclePreparedStatement.java:2190)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3334)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3423)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.pmiExecuteUpdate(WSJdbcPreparedStatement.java:948)
[6/27/07 11:27:57:643 EDT] 00000024 SystemErr R at com.ibm.ws.rsadapter.jdbc.WSJdbcPreparedStatement.executeUpdate(WSJdbcPreparedStatement.java:615)