AutoCommit Issue

Hello,
I recently switched oracle drivers (using wls8.1, sp3 weblogic.jdbc.oracle.OracleDriver). I do an autoCommit(false), though it seems to ignore it. The executeUpdates seem to happen with no commit(). I actually had to remove the commit because i was getting an error like this:
java.sql.SQLException: Cannot call Connection.commit in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed.
The oracle version is 8.1.7
Any guidence would be great, should i be using the XA driver instead?
Thanks!

"James Bort" <[email protected]> wrote in message news:29237217.1095360506265.JavaMail.root@jserv5...
I recently switched oracle drivers (using wls8.1, sp3 weblogic.jdbc.oracle.OracleDriver). I do an autoCommit(false), though itseems to ignore it. The executeUpdates seem to happen with no commit(). I actually had to remove the commit because i was getting
an error like this:
>
java.sql.SQLException: Cannot call Connection.commit in distributed transaction. Transaction Manager will commit the resourcemanager when the distributed transaction is committed.
>
The oracle version is 8.1.7
Any guidence would be great, should i be using the XA driver instead?James,
Are you using TXDataSource? If yes, you should not try to control
the commit mode - weblogic TX coordinator will do it for you. Let
me know if you have more questions.
Regards,
Slava Imeshev

Similar Messages

Reconnect policy with MySQL failing because of autoCommit error

This related to this issue, but I didn't see any responses to it: Reconnecting a dead connection from a UnitOfWork commit - Autocommit error
I'm testing with MySQL 4.1 and I have a reconnect policy that does the following (I believe this is a pretty standard approach):
session.setExceptionHandler( new ExceptionHandler() {
public Object handleException(RuntimeException exception) {
if (exception instanceof DatabaseException) {
dbex.getAccessor().reestablishConnection(dbex.getSession());
However, when it reestablishes the connection (and I have traced this and can verify that this code is executing and a reconnect is performed), I get the following error for any updates:
Internal Exception: java.sql.SQLException: Can't call rollback when autocommit=trueError Code: 0
at oracle.toplink.exceptions.DatabaseException.sqlException(DatabaseException.java:277)
at oracle.toplink.internal.databaseaccess.DatabaseAccessor.basicRollbackTransaction(DatabaseAccessor.java:1090)
at oracle.toplink.internal.databaseaccess.DatasourceAccessor.rollbackTransaction(DatasourceAccessor.java:486)
at oracle.toplink.internal.databaseaccess.DatabaseAccessor.rollbackTransaction(DatabaseAccessor.java:1075)
at oracle.toplink.publicinterface.Session.basicRollbackTransaction(Session.java:377)
I only have this problem with the MySQL JDBC drivers. I can continue to read normally, but I can't perform any transactions.
This isn't so much of a question about MySQL specifically, but rather a question about how reestablishConnection() connects to the database differently from my initial login using DatabaseLogin. Obviously, I don't have this error connecting normally. I only get it after a reconnect is applied.
Specific questions are: Is there another handler I can add to ensure JDBC Connections returned by ServerSession are always setAutoCommit(false)? Am I reestablishing the JDBC connections incorrectly?
Nate

Nate,
This does appear to be MySQL JDBC specific but is most likely related to a general issue.
When the connection drops and you receive the notification through the exception handler I would typically recommend looking at the session in us (isUnitOfWork) or the query type (isWriteObjectQuery) to see if the operation that failed was involved in a transaction (UnitOfWork commit).
In these transaction cases you need to do more then just re-connect and retry. You need to ensure after reconnection that an application exception is raised so the UnitOfWork operation(s) can be retried completely. I would simply add to this case to ensure that the JDBC connection is put back in a state where it can be managed properly.
There is no special operation or any case I know of where any special auto-commit needs to be set on a connection after it has dropped and before it is re-connected.
Doug

Issue while Processing the Huge File in BPEL

Hi,
We are facing an Issue while Processing a Hige file in BPEL Process (More than 1MB File). When i test the files with more than 1500 transactions (More than 1MB file) then the BPEL Process is automatically goes to OFF Mode or it goes to Perform Manually Recovery Queue.
Even we are facing this issue in Production also so we are using UNIX Script to Split the file before place the file in BPEL Input directory.Any Pointers to resolve this issue will be helpful.
Thanks,
Saravana

Hi,
Please find the answers.
1. Currently we are using SOA 10.1.2 Version and JDev10g
2. we are using File Adapeter
3. yes. We used debatching.
4. Yes. I am able to recover from Manual Recovery Queue
5. Please find the error message
<2009-05-21 04:32:38,461> <DEBUG> <ESIBT.collaxa.cube.engine.dispatch> <Dispatcher::adjustThreadPool> Allocating 1 thread(s); pending threads: 1, active threads: 0, total: 83
<2009-05-21 04:32:44,077> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> File : /harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B is ready to be processed.
<2009-05-21 04:32:44,077> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Processing file : /harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B
<2009-05-21 04:32:44,077> <DEBUG> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> onBatchBegin: Batch 'bpel://localhost/ESIBT/BPELProcess_810~1.0//Input5162009.B2B_1242894594000' (/harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B) starting...
<2009-05-21 04:32:44,077> <DEBUG> <ESIBT.collaxa.cube.translation> <TranslatorFactory::log> Inside TranslatorFactory
<2009-05-21 04:32:44,078> <DEBUG> <ESIBT.collaxa.cube.translation> <TranslatorFactory::log> using version attribute = NXSD
<2009-05-21 04:32:44,078> <DEBUG> <ESIBT.collaxa.cube.translation> <TranslatorFactory::log> loading xlator class...oracle.tip.pc.services.translation.xlators.nxsd.NXSDTranslatorImpl
<2009-05-21 04:32:44,081> <DEBUG> <ESIBT.collaxa.cube.translation> <TranslatorFactory::log> class loaded
<2009-05-21 04:32:44,081> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Created translator : oracle.tip.pc.services.translation.xlators.nxsd.NXSDTranslatorImpl@46908ae8
<2009-05-21 04:32:44,098> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Setting up Control dir for debatching error recovery
<2009-05-21 04:32:44,121> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Control dir for debatching error recovery : /opt01/app/ESIBT/oracle/esibt10gR2iAS/BPEL10gR2/iAS/j2ee/home/fileftp/controlFiles/localhost_ESIBT_BPELProcess_810~1.0_/inbound
<2009-05-21 04:32:44,121> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Invoking inbound translation for : Input5162009.B2B
<2009-05-21 04:32:44,121> <DEBUG> <ESIBT.collaxa.cube.translation> <NXSDTranslatorImpl::log> Starting translateFromNative
<2009-05-21 04:32:44,139> <DEBUG> <ESIBT.collaxa.cube.translation> <NXSDTranslatorImpl::log> Done with translateFromNative
<2009-05-21 04:32:44,139> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Completed inbound translation for : Input5162009.B2B
<2009-05-21 04:32:44,139> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> isTextFile : true
<2009-05-21 04:32:44,139> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Translated inbound batch index 1 of file {Input5162009.B2B} with corrupted message count = 1
<2009-05-21 04:32:44,139> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Error Reader created using charset :ASCII
<2009-05-21 04:32:44,139> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Sending message to Adapter Framework for rejection to user-configured rejection handlers : {
fileName=/harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B, startLine=1, startColumn=1, endLine=-1, endCol=-1, Exception=ORABPEL-11167
Error while reading native data.
[Line=1, Col=70] Expected "\t" at the specified position in the native data, while trying to read the data for "element with name HDR_STORE_NUM", using "style" as "terminated" and "terminatedBy" as "\t", but not found.
Ensure that "\t", exists at the specified position in the native data.
<2009-05-21 04:32:44,139> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Setting batchId in NativeRecord to bpel://localhost/ESIBT/BPELProcess_810~1.0//Input5162009.B2B_1242894594000
<2009-05-21 04:32:44,139> <WARN> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> [Read_ptt::Read(Object)] - onReject: The resource adapter 'File Adapter' requested handling of a malformed inbound message. However, the following bpel.xml activation property has not been defined: 'rejectedMessageHandlers'. Please define it and redeploy the business process. Will use the default Rejection Directory file:///opt01/app/ESIBT/oracle/esibt10gR2iAS/BPEL10gR2/iAS/integration/orabpel/domains/ESIBT/archive/jca/BPELProcess_810/rejectedMessages for now.
<2009-05-21 04:32:44,140> <WARN> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> [Read_ptt::Read(Object)] - onReject: Sending invalid inbound message to Exception Handler:
<2009-05-21 04:32:44,140> <INFO> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> Handing rejected message to DEFAULT rejection handler: file:///opt01/app/ESIBT/oracle/esibt10gR2iAS/BPEL10gR2/iAS/integration/orabpel/domains/ESIBT/archive/jca/BPELProcess_810/rejectedMessages since none of the configured rejection handlers [] succeeded.
<2009-05-21 04:32:44,140> <DEBUG> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> Finished persisting rejected message to file system under the name: /opt01/app/ESIBT/oracle/esibt10gR2iAS/BPEL10gR2/iAS/integration/orabpel/domains/ESIBT/archive/jca/BPELProcess_810/rejectedMessages/INVALID_MSG_BPELProcess_810_Read_20090521_043244_0140.dat
<2009-05-21 04:32:44,141> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Setting last error record to : -1
<2009-05-21 04:32:44,141> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Translator has failed to translate any message from batch number: 1
<2009-05-21 04:32:44,141> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Message not published as translation failed: {
File=/harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B, batchIndex=1, PublishSize=1
<2009-05-21 04:32:44,141> <ERROR> <ESIBT.collaxa.cube.activation> <AdapterFramework::Inbound> onBatchFailure: Batch 'bpel://localhost/ESIBT/BPELProcess_810~1.0//Input5162009.B2B_1242894594000' (/harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B) has failed due to: ORABPEL-11167
Error while reading native data.
[Line=1, Col=70] Expected "\t" at the specified position in the native data, while trying to read the data for "element with name HDR_STORE_NUM", using "style" as "terminated" and "terminatedBy" as "\t", but not found.
Ensure that "\t", exists at the specified position in the native data.
<2009-05-21 04:32:44,141> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Deleting file : /harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B after processing.
<2009-05-21 04:32:44,141> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Deleting file : Input5162009.B2B
<2009-05-21 04:32:44,141> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Deleted file : true
<2009-05-21 04:32:44,141> <DEBUG> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Removing file /harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B from files to be processed Map.
<2009-05-21 04:32:44,141> <INFO> <ESIBT.collaxa.cube.activation> <File Adapter::Inbound> Done processing File : /harbinger/prod/xlate/Outbound_Input_LDS_810/Input5162009.B2B
<2009-05-21 04:33:09,698> <DEBUG> <ESIBT.collaxa.cube.engine.data> <ConnectionFactory::getConnection> GOT CONNECTION 4 Autocommit = false
For this error message this shows due to some /t its not picking up the file. but even i am facing the same issue for all the files where load is huge.
Thanks,
Saravana

Cannot add column to flexible table when ddl autocommit is off using Procedure

Hello All,
Through procedure I am trying to insert data into the target(EX_92) table(with schema flexibility)
Source table data
ID
PRODUCT_CODE
PRODUCT_NAME
PRICE
COLOR
TYPE
1
1
rugg
101.22
2
1
rugg
101.22
3
2
book
200.32
BLUE
Y
Target table QUERY
drop table EX_P2;
CREATE COLUMN TABLE EX_P2(
ID INTEGER PRIMARY KEY,
PRODUCT_CODE VARCHAR(3),
PRODUCT_NAME NVARCHAR(20),
PRICE DECIMAL(5,2)
) WITH SCHEMA FLEXIBILITY;
Procedure to insert above records with additional columns into the target table(EX_P2)
Procedure
drop procedure "DS_O1"."PROC";
create procedure "DS_O1"."PROC"(IN max_value INTEGER, IN schema_name varchar(40), IN table_name varchar(40), IN column_list varchar(400))
LANGUAGE SQLSCRIPT AS
BEGIN
DECLARE maxid integer :=0;
DECLARE INSERT_STR VARCHAR(1000) :='';
select max(ID) into maxid from "DS_O1"."EX_P2";
select :maxid from dummy;
INSERT_STR :='insert into "' || 'DS_O1' ||'"."EX_P2" ('||:column_list||') (select ' ||:column_list||'
FROM "'||:schema_name||'"."'||:table_name||'"' || ' where ID >' || :max_value || ')';
EXECUTE immediate(:INSERT_STR);
END;
Now while executing above procedure
CALL "DS_O1"."PROC" ( 0, 'DS_O1', 'TMP_EXL2','ID,PRODUCT_CODE,PRODUCT_NAME,PRICE,COLOR,STATUS,TYPE');
I am getting the following error
Could not execute 'CALL "DS_O1"."PROC" ( 0, 'DS_O1', 'TMP_EXL2','ID,PRODUCT_CODE,PRODUCT_NAME,PRICE,COLOR,STATUS,TYPE')' in 23 ms 564 µs .
SAP DBTech JDBC: [7]: feature not supported: [7] "DS_O1"."PROC": line 18 col 1 (at pos 779): [7] (range 3): feature not supported: cannot add column to flexible table when ddl autocommit is off

Hi Rajnish,
I had the same issue. For what it’s worth I was able to do a workaround basically creating all the columns when I create the table. The following code works for me to create the table which is just a matrix with one Integer column as the key and the rest as type Double.
It is not ideal in all scenarios because the table columns cannot be added dynamically via a procedure at a later point. This table has 27K columns now
Of course one of the advantages of a flex table would be programmatically adding columns dynamically. This works, but maybe there is still a way to add columns dynamically from a procedure, and someone else can advise.
Apparently dynamically adding columns via procedures may have some "minor" limitations due to the need to compile the procedure with knowledge of the flex table DDL. But again, hopefully someone knows another solution.
Best regards,
Mark
DROP PROCEDURE CREATE_MATRIX;
CREATE PROCEDURE CREATE_MATRIX(
    LANGUAGE SQLSCRIPT
    SQL SECURITY INVOKER
    AS
/*********BEGIN PROCEDURE SCRIPT ************/
BEGIN
    -- cursor over messages
    declare cursor matrix_cursor for
        select distinct TERM
        from TERMS
        order by term;
       declare cnt INTEGER := 0;
       declare temptxt NVARCHAR(500000) := 'CREATE COLUMN TABLE DOC_MATRIX ( CONTENT_ID INTEGER ';
    for cur_matrix as matrix_cursor do
      cnt:=:cnt + 1;
           select temptxt || ', C' || cnt || ' DOUBLE' into temptxt from dummy;
    end for;
      temptxt:=temptxt || ' ) WITH SCHEMA FLEXIBILITY';
       EXEC :temptxt;
       select :temptxt from dummy;
END;
DROP TABLE DOC_MATRIX;
CALL CREATE_MATRIX();

JDBC Thin Driver Won't Honor Autocommit=FALSE

I have the following code, which intializes a JDBC thin driver connection, and sets the autocommit to false. However, as soon as the statement is executed, it commits on its own. What's going wrong here? I can tell that it is committing, because the calendar events all disappear, even if the code is terminated before committing, or in an endless loop.
odsSecondary = new OracleDataSource();
odsSecondary.setDatabaseName("####");
odsSecondary.setDriverType("thin");
odsSecondary.setUser("####");
odsSecondary.setPassword("####");
odsSecondary.setPortNumber(1521);
odsSecondary.setServerName("####");
connectionSecondary = odsSecondary.getConnection();
connectionSecondary.setAutoCommit(false);
Statement stmtSecondary = connectionSecondary.createStatement();
stmtSecondary.executeUpdate("truncate table cal_events");

The truncate command always issues a commit. refer to the oracle SQL documentation

MySQL Exception in WL 8.1 - Can't call commit when autocommit=true

Thanks in advance. Any help would be appreciated as I'm new to Weblogic. I've created a database control and get the following error at run time that I can't seem to get around:
An unexpected exception occurred while attempting to locate the run-time information for this Web Service. Error: java.sql.SQLException:
The server trace is as follows:
####<Jul 23, 2004 8:54:08 AM CDT> <Error> <WLW> <dts-client1> <cgServer> <ExecuteThread: '11' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Exception processing ManageRouteTableJCS.ManageRouteTableTest
java.sql.SQLException: Can't call commit when autocommit=true
     at com.mysql.jdbc.Connection.commit(Connection.java:1136)
     at weblogic.jdbc.wrapper.PoolConnection_com_mysql_jdbc_Connection.commit(Unknown Source)
     at com.bea.wlw.runtime.core.bean.BMPContainerBean.initTableAccess(BMPContainerBean.java:1650)
     at com.bea.wlw.runtime.core.dispatcher.DispComponentJar.confirmDeployment(DispComponentJar.java:157)
     at com.bea.wlw.runtime.core.dispatcher.DispResources.confirmDeployment(DispResources.java:754)
     at com.bea.wlw.runtime.core.dispatcher.DispCache.ensureDispUnit(DispCache.java:660)
     at com.bea.wlw.runtime.core.dispatcher.HttpServerHelper.getDispUnit(HttpServerHelper.java:501)
     at com.bea.wlw.runtime.core.dispatcher.HttpServerHelper.executeGetRequest(HttpServerHelper.java:541)
     at com.bea.wlw.runtime.core.dispatcher.HttpServer.doGet(HttpServer.java:81)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:996)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6456)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3661)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2630)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Note that the above error only occurs with the database control. When I use the following straight Java code I can read records from the database just fine:
<%@page import="javax.naming.*,javax.sql.*,java.sql.*"%>
<%
Context ctx = new InitialContext ( );
DataSource dataSource = (DataSource) ctx.lookup ( "MySQLDataSource" );
Connection connection = dataSource.getConnection ( );
Statement statement = connection.createStatement ( );
ResultSet result = statement.executeQuery ( "select * from myTable1" );
while ( result.next ( ) ) {
out.print ( result.getString ( "field1" ) );
out.print ( "<br>" );
connection.close ( );
%>
I have experimented with disabling autconnect at the datasource with no change to the behavior.
Environmet specifics:
- Weblogic 8.1/SP3 (had the issue with SP2)
- MySQL standard 4.1 (had the issue with 4.0 and MaxDB)
- mysql-connector-java-3.0.14-production
I have read many articles on using using MySQL and Weblogic using I/O classes but not an article where a control was created in design view as I have done. Since I am able to read from the database with the executeQuery command I am led to believe that I have the database and driver set up correctly.
Anyone run into this and have an idea of what I don't have configured properly?
Thanks,
David

Thanks in advance. Any help would be appreciated as I'm new to Weblogic. I've created a database control and get the following error at run time that I can't seem to get around:
An unexpected exception occurred while attempting to locate the run-time information for this Web Service. Error: java.sql.SQLException:
The server trace is as follows:
####<Jul 23, 2004 8:54:08 AM CDT> <Error> <WLW> <dts-client1> <cgServer> <ExecuteThread: '11' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Exception processing ManageRouteTableJCS.ManageRouteTableTest
java.sql.SQLException: Can't call commit when autocommit=true
     at com.mysql.jdbc.Connection.commit(Connection.java:1136)
     at weblogic.jdbc.wrapper.PoolConnection_com_mysql_jdbc_Connection.commit(Unknown Source)
     at com.bea.wlw.runtime.core.bean.BMPContainerBean.initTableAccess(BMPContainerBean.java:1650)
     at com.bea.wlw.runtime.core.dispatcher.DispComponentJar.confirmDeployment(DispComponentJar.java:157)
     at com.bea.wlw.runtime.core.dispatcher.DispResources.confirmDeployment(DispResources.java:754)
     at com.bea.wlw.runtime.core.dispatcher.DispCache.ensureDispUnit(DispCache.java:660)
     at com.bea.wlw.runtime.core.dispatcher.HttpServerHelper.getDispUnit(HttpServerHelper.java:501)
     at com.bea.wlw.runtime.core.dispatcher.HttpServerHelper.executeGetRequest(HttpServerHelper.java:541)
     at com.bea.wlw.runtime.core.dispatcher.HttpServer.doGet(HttpServer.java:81)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:996)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:419)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:315)
     at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6456)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
     at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3661)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2630)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:219)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)
Note that the above error only occurs with the database control. When I use the following straight Java code I can read records from the database just fine:
<%@page import="javax.naming.*,javax.sql.*,java.sql.*"%>
<%
Context ctx = new InitialContext ( );
DataSource dataSource = (DataSource) ctx.lookup ( "MySQLDataSource" );
Connection connection = dataSource.getConnection ( );
Statement statement = connection.createStatement ( );
ResultSet result = statement.executeQuery ( "select * from myTable1" );
while ( result.next ( ) ) {
out.print ( result.getString ( "field1" ) );
out.print ( "<br>" );
connection.close ( );
%>
I have experimented with disabling autconnect at the datasource with no change to the behavior.
Environmet specifics:
- Weblogic 8.1/SP3 (had the issue with SP2)
- MySQL standard 4.1 (had the issue with 4.0 and MaxDB)
- mysql-connector-java-3.0.14-production
I have read many articles on using using MySQL and Weblogic using I/O classes but not an article where a control was created in design view as I have done. Since I am able to read from the database with the executeQuery command I am led to believe that I have the database and driver set up correctly.
Anyone run into this and have an idea of what I don't have configured properly?
Thanks,
David

WLS 10.3.0.0 Solaris SPARC and DBMS Oracle 10gR2 connection pooling issue

Hi all,
we are currently testing Weblogic Server 10.3.0.0 in order to migrate our production system from WLS 8.1 to it.
While testing the new setup, we encountered some strange behaviour of the connection pooling within WLS.
We configured a XA-Connection pool to our DB (Oracle 10gR2) by using
a) the Oracle XA-thin-driver delivered within WLS 10.3.0.0
and alternatively
b) the Oracle 11.2.0.2 OCI-driver of the Oracle 11g database client.
We´ve got the same issue with both variants. We defined an initial capacity of 5 connections and a maximum capacity of 30 connections.
Our application is running flawlessly using the connection pool, but the amount of active sessions between the application server and the database server is increasing rapidly and the maximum capacity is exceeded. We are seeing up to multiple hundreds of sessions from the application server to our database server. Obviously the connections aren´t cleaned up.
We are using the following settings for the JDBC-Connection:
initial capacity = 5
max. capacity = 30
Capacity increment = 1
Statement cache type = LRU
Statement cache size = 10
Test connections on reserve = true
Test frequency = 120
Test table name = "sql select 1 from dual"
seconds to trust an idle pool connection = 10
shrink frequency = 0
connecttion creation retry frequency = 120
login delay = 0
incative connection timeout = 10
max. waiting for connection = 2147483647
connection reserve timeout= = -1
Ignare in-use connections = true
pinned-to-thread = false
remoce infected connections enabled = true
Does anyone have an idea how to track/solve this issue?
Kind regards
Marc

Hi Joe,
we´ve tested with the thin driver using an initial capacity of 5 and a maximum capacity of 15. During our tests (in a very short time period) the maximum capacity has not been exceeded. But we saw some exceptions in the managed server logfile which made us curious.
When these exceptions are occuring, a new connection to the database server is established. We are seeing for a short time a total count of 6 connections which is immediately decreasing to the initial capacity of 5. We will do some further testing over the next hours and monitor the connection usage.
The connection we are dealing with is the one called "ZDB2".
This is an excerpt of the logfile:
####<18.10.2010 19:45 Uhr MESZ> <Debug> <JDBCConn> <SERVER-NAME> <MANAGED SERVER NAME> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-02F7EA174F1D84653A69> <> <1287423940610> <BEA-000000> <java.lang.Exception: Pinned: autoCommit=true,enabled=true,isXA=true,isJTS=false,vendorID=0,connUsed=true,doInit=false,'null',destroyed=false,poolname=ZDB2,appname=null,moduleName=null,connectTime=177,dirtyIsolationLevel=false,initialIsolationLevel=2,infected=true,lastSuccessfulConnectionUse=1287423940605,secondsToTrustAnIdlePoolConnection=10,currentUser=java.lang.Exception
     at weblogic.jdbc.common.internal.ConnectionEnv.setup(ConnectionEnv.java:308)
     at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:314)
     at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:427)
     at weblogic.jdbc.common.internal.ConnectionPool.reserve(ConnectionPool.java:316)
     at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:93)
     at weblogic.jdbc.common.internal.ConnectionPoolManager.reserve(ConnectionPoolManager.java:61)
     at weblogic.jdbc.jta.DataSource.getXAConnectionFromPool(DataSource.java:1473)
     at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1272)
     at weblogic.jdbc.jta.DataSource.getConnection(DataSource.java:425)
     at weblogic.jdbc.jta.DataSource.connect(DataSource.java:382)
     at weblogic.jdbc.common.internal.RmiDataSource.getConnection(RmiDataSource.java:338)
     at org.hibernate.connection.DatasourceConnectionProvider.getConnection(DatasourceConnectionProvider.java:69)
     at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423)
     at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
     at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
     at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547)
     at org.hibernate.loader.Loader.doQuery(Loader.java:673)
     at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
     at org.hibernate.loader.Loader.doList(Loader.java:2220)
     at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
     at org.hibernate.loader.Loader.list(Loader.java:2099)
     at org.hibernate.hql.classic.QueryTranslatorImpl.list(QueryTranslatorImpl.java:912)
     at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
     at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
     at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
     at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:811)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderPersistenceGenerated.findByPrimaryKey(OrderPersistenceGenerated.java:45)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImplStandard.findOrderByPrimaryKey(OrderManagementServiceImplStandard.java:1356)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.findOrderByPrimaryKeyTx(OrderManagementServiceTransactionHandler.java:830)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceSessionBean.findOrderByPrimaryKey(OrderManagementServiceSessionBean.java:1276)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_ELOImpl.findOrderByPrimaryKey(OrderManagementEJB_yb2dzq_ELOImpl.java:19812)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceApplicationProxy.findOrderByPrimaryKey(OrderManagementServiceApplicationProxy.java:1289)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.findOrderByPrimaryKey(OrderManagementServiceTransactionHandler.java:823)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImplStandard.findOrderByPrimaryKey(OrderManagementServiceImplStandard.java:1341)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.findOrderByPrimaryKeyTx(OrderManagementServiceTransactionHandler.java:816)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceSessionBean.findOrderByPrimaryKey(OrderManagementServiceSessionBean.java:1255)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_ELOImpl.findOrderByPrimaryKey(OrderManagementEJB_yb2dzq_ELOImpl.java:7332)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceApplicationProxy.findOrderByPrimaryKey(OrderManagementServiceApplicationProxy.java:1266)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.findOrderByPrimaryKey(OrderManagementServiceTransactionHandler.java:809)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImpl.publishOrder(OrderManagementServiceImpl.java:1636)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImpl.savePublishedOrder(OrderManagementServiceImpl.java:1606)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.savePublishedOrderTx(OrderManagementServiceTransactionHandler.java:3467)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceSessionBean.savePublishedOrder(OrderManagementServiceSessionBean.java:5272)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl.savePublishedOrder(OrderManagementEJB_yb2dzq_EOImpl.java:3263)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.internalInvoke2(Unknown Source)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.internalInvoke1(Unknown Source)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.invoke(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
     at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
     at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
     at weblogic.security.service.SecurityManager.runAs(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
     at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
,currentThread=Thread[[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)',5,Pooled Threads],lastUser=null,currentError=null,currentErrorTimestamp=null,JDBC4Runtime=true,supportStatementPoolable=true,needRestoreClientInfo=false,defaultClientInfo={} is set to be refreshed
     at weblogic.jdbc.common.internal.ConnectionEnv.setRefreshNeeded(ConnectionEnv.java:518)
     at weblogic.jdbc.wrapper.Connection.getVendorConnection(Connection.java:292)
     at de.dpcom.persistence.hibernate.BinaryBlobType.nullSafeSet(BinaryBlobType.java:109)
     at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:146)
     at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:1997)
     at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2371)
     at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2307)
     at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2607)
     at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:92)
     at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248)
     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232)
     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140)
     at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
     at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
     at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CertificatePersistenceGenerated.updateCertificate(CertificatePersistenceGenerated.java:116)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CustomerManagementServiceImplStandard.updateCertificate(CustomerManagementServiceImplStandard.java:1282)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CustomerManagementServiceTransactionHandler.updateCertificateTx(CustomerManagementServiceTransactionHandler.java:711)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CustomerManagementServiceSessionBean.updateCertificate(CustomerManagementServiceSessionBean.java:1104)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CustomerManagementEJB_ap2i9a_ELOImpl.updateCertificate(CustomerManagementEJB_ap2i9a_ELOImpl.java:19199)
     at APPNAME-ROOT-PATH.components.customermanagement.biz.CustomerManagementServiceApplicationProxy.updateCertificate(CustomerManagementServiceApplicationProxy.java:1101)
     at APPNAME-ROOT-PATH.components.productionresultprocessing.biz.ProductionResultProcessingServiceImpl.publishCertificate(ProductionResultProcessingServiceImpl.java:1131)
     at APPNAME-ROOT-PATH.components.productionresultprocessing.biz.ProductionResultProcessingServiceTransactionHandler.publishCertificateTx(ProductionResultProcessingServiceTransactionHandler.java:298)
     at APPNAME-ROOT-PATH.components.productionresultprocessing.biz.ProductionResultProcessingServiceSessionBean.publishCertificate(ProductionResultProcessingServiceSessionBean.java:517)
     at APPNAME-ROOT-PATH.components.productionresultprocessing.biz.ProductionResultProcessingServiceSessionBean_yaua6q_ELOImpl.publishCertificate(ProductionResultProcessingServiceSessionBean_yaua6q_ELOImpl.java:1804)
     at APPNAME-ROOT-PATH.components.productionresultprocessing.biz.ProductionResultProcessingServiceApplicationProxy.publishCertificate(ProductionResultProcessingServiceApplicationProxy.java:471)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImpl.publishCertificate(OrderManagementServiceImpl.java:1825)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImpl.publishOrder(OrderManagementServiceImpl.java:1664)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceImpl.savePublishedOrder(OrderManagementServiceImpl.java:1606)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceTransactionHandler.savePublishedOrderTx(OrderManagementServiceTransactionHandler.java:3467)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementServiceSessionBean.savePublishedOrder(OrderManagementServiceSessionBean.java:5272)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl.savePublishedOrder(OrderManagementEJB_yb2dzq_EOImpl.java:3263)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.internalInvoke2(Unknown Source)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.internalInvoke1(Unknown Source)
     at APPNAME-ROOT-PATH.components.ordermanagement.biz.OrderManagementEJB_yb2dzq_EOImpl_WLSkel.invoke(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:589)
     at weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:230)
     at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:477)
     at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
     at weblogic.security.service.SecurityManager.runAs(Unknown Source)
     at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:473)
     at weblogic.rmi.internal.wls.WLSExecuteRequest.run(WLSExecuteRequest.java:118)
     at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
     at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
>
####<18.10.2010 19:45 Uhr MESZ> <Info> <JDBC> <SERVER-NAME> <MANAGED SERVER NAME> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1287423940797> <BEA-001072> <Connection for XA pool "ZDB2" created.>
####<18.10.2010 19:45 Uhr MESZ> <Info> <JDBC> <SERVER-NAME> <MANAGED SERVER NAME> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1287423940808> <BEA-001132> <Initialized statement cache of size "10" for connection in pool "ZDB2".>
####<18.10.2010 19:45 Uhr MESZ> <Info> <Common> <SERVER-NAME> <MANAGED SERVER NAME> <[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1287423940808> <BEA-000628> <Created "1" resources for pool "ZDB2", out of which "1" are available and "0" are unavailable.>
Any suggestions?
Kind regards
Marc

FORALL and autocommit behavour

Hi everyone,
I have to to remove a large amount of double entries from a huge table based on three different criteria.
The affected database is running 24/7 with a lot of concurrent access including many DML commands. There is no possibility to lock the DB while the cleanup script is running.
So far I've used a PL/SQL script which is doing mainly the following steps:
1. Get a list of Ids (both primary key id and internal ID) via BULK collect into a collection (May contain upto 1.500.000 records to remove)
2. Pass the retrieved data to FORALL to actually remove these values
3. Finally commit
Tests on our Test environment shows that the runtime might easily exceed 6-8 hours (the affected table is really large) per Script. So my collegues asked me to perform a commit every 2000 records.
I'm not sure if FORALL utilises the SQL*Plus feature "SET AUTOCOMMIT ON 2000" ?
If this is not the case (which I assume), is there any other way to foce FORALL to commit on every 'N' records? Or do I have to change the code to use the BULK COLLECT LIMIT clause and feed FORALL with that "batch"?
Hope that someone could give some hints on that topic.
Thanks for help!
Best regards,
Sascha

user12865818 wrote:
Tests on our Test environment shows that the runtime might easily exceed 6-8 hours (the affected table is really large) per Script. So my collegues asked me to perform a commit every 2000 records.Your colleagues are idiots.
With that volume size, your code will be fetching across commits (a violation of ANSI SQL standards) - and it will run into ORA-01555: snapshot too old.
Firstly identify WHAT the performance problem is. That is pretty easy as you have a "really large table" that needs every single row read to be checked for duplicates.
So the performance issue is I/O. I/O is the slowest operation on a database. As your code needs to check every single row, every single row needs to be read. Indexes cannot provide a faster and better path (using an index in such a case will only cause more I/O and performance degradation).
How do you address an I/O performance problem? By doing more commits!? That is laughable. And does not in ANY way reduce the amount of I/O that needs to be done.
I/O is addressed at application level by two simple methods:
1) do less I/O
2) do I/O in parallel
You need to make sure that the method you use for identifying the duplicates are optimal. The least amount of I/O to achieve the desired result.
Secondly, as the entire table needs to be processed, you can do that in parallel. Oracle supports Parallel Query (PQ) for both DML and DDL statements. You can use DBMS_PARALLEL_EXECUTE. You can manually determine the physical row address range of that table, and break that up into multiple subranges - and execute your code in parallel, for each of the subranges.
Increasing the commit frequency simply means MORE work needs to be done... and the real performance problem, the amount of I/O, is not made one teeny bit faster.

DBAdapter polling for new or changed records not issuing callback?

I have a process which includes a partner link with a database adapter.
The database adapter is to poll a table for new records using an external database server.
I have no relationships setup, it's a single-table query.
The adapter is configured to delete rows after they are read.
I have the receive process of that partner link tied to a receive activity and its own input variable assigned.
My process compiles and deploys successfully. When I initiate the process through the BPEL console, the instance of the process waits at the receive activity and nothing happens, even after I manually add records to the table being polled. (which do get deleted, apparently by the partner link.)
I have other dbadapter partner links in the same process using the same connection that work fine, specifically using procedure execution and custom sql queries.
I can't find any errors or warnings about this, and the interactions manager in the BPEL Console allows me to manually send a message to the instance, allowing it to continue.
The application server is 10.1.3.1.0 and I am using JDeveloper 10.1.3.2.0.4066
Message was edited by:
Paul.Dunbar
Follow-up:
When I set activation logging to debug, I get the following in domain.log
<2007-04-03 08:15:28,591> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> client acquired
<2007-04-03 08:15:28,591> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> SELECT SOME_ID, SOME_VALUE FROM PAULD.SOME_TABLE ORDER BY SOME_ID ASC
<2007-04-03 08:15:28,592> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> client released
From looking at this it may be that the callback to the receive activity is not occurring?
Message was edited by:
Paul.Dunbar
Second follow-up:
I'm still having this issue but must give up on troubleshooting.
Documentation on polling adapter says nothing about handling callbacks, I've been trying to use correlations here with no luck. I'm also not seeing any documentation about setting up correlations for use with the database adapter.
now the issue I'm having is that the inbound database adapter is still polling my table and deleting records, even though I've undeployed my process.

I did not. Currently the manual recovery area is empty. I've tried re-deploying my process and am now getting the following in my logs (all debugging on):
<2007-04-05 08:01:36,671> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired read lock for SendEventNotice-1.0
<2007-04-05 08:01:36,671> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::release> Released lock for SendEventNotice-1.0
<2007-04-05 08:01:36,672> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired read lock for SendEventNotice-1.0
<2007-04-05 08:01:36,672> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::release> Released lock for SendEventNotice-1.0
<2007-04-05 08:01:36,678> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::getConnection> GOT CONNECTION 1 Autocommit = false
<2007-04-05 08:01:36,681> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::closeConnection> CLOSE CONNECTION 0
<2007-04-05 08:01:36,681> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::getConnection> GOT CONNECTION 1 Autocommit = false
<2007-04-05 08:01:36,682> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::closeConnection> CLOSE CONNECTION 0
<2007-04-05 08:01:36,686> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired read lock for SendEventNotice-1.0
<2007-04-05 08:01:36,687> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::release> Released lock for SendEventNotice-1.0
<2007-04-05 08:01:36,688> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired read lock for SendEventNotice-1.0
<2007-04-05 08:01:36,688> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::release> Released lock for SendEventNotice-1.0
<2007-04-05 08:01:36,688> <DEBUG> <default.collaxa.cube.engine.deployment> <LockManager::acquire> Acquired write lock for SendEventNotice-1.0
<2007-04-05 08:01:36,688> <DEBUG> <default.collaxa.cube.engine.data> <BaseProcessPersistenceAdaptor::updateMetaData> Updating process metadata [ domain = default, process = SendEventNotice, revision = 1.0, state = 0, lifecycle = 0 ]
<2007-04-05 08:01:36,688> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::getConnection> GOT TX CONNECTION 1 Autocommit = false
<2007-04-05 08:01:36,691> <DEBUG> <default.collaxa.cube.engine.dispatch> <BaseDispatchSet::receive> Receiving message log process event message 61b55bd8c71ae1e3:-3d66bcb1:111c1b2d4aa:-7f9c for set system
<2007-04-05 08:01:36,691> <DEBUG> <default.collaxa.cube.engine.dispatch> <Dispatcher::adjustThreadPool> Allocating 1 thread(s); pending threads: 1, active threads: 0, total: 84
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine.dispatch> <DispatcherBean::send> Sent message to queue
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class oracle.bpel.services.rules.DeploymentListener with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class com.collaxa.cube.engine.test.driver.deployment.BPELTestDeployer with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class oracle.bpel.services.workflow.task.PurgeTask with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.services> <oracle.bpel.services.workflow.task.PurgeTask::update(ICubeAspect> Called for aspect com.collaxa.cube.engine.observer.ProcessStateChangeAspect
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class oracle.tip.esb.configuration.deployment.bpel.BPELSvcDeploymentManager with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine.dispatch> <SystemDispatchSet::fetchScheduled> Fetched message log process event message 61b55bd8c71ae1e3:-3d66bcb1:111c1b2d4aa:-7f9c from system queue for processing
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine.dispatch> <LogProcessEventMessageHandler::handle> Processing log process event message 61b55bd8c71ae1e3:-3d66bcb1:111c1b2d4aa:-7f9c
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class com.collaxa.cube.engine.data.CubeInstanceCache with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class oracle.bpel.services.workflow.DeploymentListener with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.services> <oracle.bpel.services.workflow.DeploymentListener::update(ICubeAspect> Called for aspect com.collaxa.cube.engine.observer.ProcessStateChangeAspect
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.engine> <DomainObserverRegistry::notify> Notifying observer class com.collaxa.cube.engine.core.BaseCubeProcess$ActivationObserver with aspect class com.collaxa.cube.engine.observer.ProcessStateChangeAspect for domain default
<2007-04-05 08:01:36,693> <INFO> <default.collaxa.cube.activation> <AdapterFramework::Inbound> JCAActivationAgent::onStateChanged State is changed for process 'bpel://localhost/default/SendEventNotice~1.0/', state=ON
<2007-04-05 08:01:36,693> <INFO> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Adapter Framework instance: OraBPEL - endpointActivation for portType=initialCoordination_ptt, operation=receive
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Looking up jca:address...
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Looking up WSDL Service jca:address for portType=initialCoordination_ptt and operation=receive
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Locating Resource Adapter for jca:address.. {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address: location='eis/DB/TST2' ManagedConnectionFactory='oracle.tip.adapter.db.DBManagedConnectionFactory' (properties: {Password=E466676A7A458FA6EBCFF72E13C04843, PlatformClassName=oracle.toplink.platform.database.oracle.Oracle10Platform, ConnectionString=jdbc:oracle:thin:@//lxdb2:1521/TST2, DriverClassName=oracle.jdbc.OracleDriver, UserName=SONRIS_DBA})
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Setting up Input Header Message QName: null
<2007-04-05 08:01:36,693> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Setting up Input Header Part Name: null
<2007-04-05 08:01:36,694> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::getConnection> GOT TX CONNECTION 2 Autocommit = false
<2007-04-05 08:01:36,694> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Setting Adapter Name: Database Adapter
<2007-04-05 08:01:36,694> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Determining Input and Output WSDL Message elements
<2007-04-05 08:01:36,695> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Creating ActivationSpec...
<2007-04-05 08:01:36,695> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Instantiating ActivationSpec oracle.tip.adapter.db.DBActivationSpec
<2007-04-05 08:01:36,695> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Populating ActivationSpec oracle.tip.adapter.db.DBActivationSpec with properties: {MaxRaiseSize=1, MarkReadFieldName=DONE_READING, UseBatchDestroy=false, MarkUnreadValue=UNREAD, ReturnSingleResultSet=false, QueryName=initialCoordination, MarkReadValue=READ, MarkReservedValue=RESERVED, DescriptorName=initialCoordination.AnotherTable, NumberOfThreads=1, MappingsMetaDataURL=initialCoordination_toplink_mappings.xml, PollingStrategyName=LogicalDeletePollingStrategy, PollingInterval=5, SequencingFieldName=AN_ID, MaxTransactionSize=unlimited}
<2007-04-05 08:01:36,697> <DEBUG> <default.collaxa.cube.engine.data> <ConnectionFactory::closeConnection> CLOSE TX CONNECTION 1
<2007-04-05 08:01:36,700> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Preparing ActivationSpec for Translation Service
<2007-04-05 08:01:36,701> <DEBUG> <default.collaxa.cube.engine.dispatch> <BaseDispatchSet::acknowledge> Acknowledged message log process event message 61b55bd8c71ae1e3:-3d66bcb1:111c1b2d4aa:-7f9c
<2007-04-05 08:01:36,705> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Preparing ActivationSpec for Connection Factory and Properties
<2007-04-05 08:01:36,705> <DEBUG> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Invoking endpointActivation() on Resource Adapter
<2007-04-05 08:01:36,708> <INFO> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.DBResourceAdapter endpointActivation> Activating: oracle.tip.adapter.db.DBActivationSpec@4e7ed
<2007-04-05 08:01:36,710> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> client acquired
<2007-04-05 08:01:36,713> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> client released
<2007-04-05 08:01:36,715> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.DBEndpoint start> About to schedule the inbound polling thread with the work manager. ActivationSpec: oracle.tip.adapter.db.DBActivationSpec@4e7ed
<2007-04-05 08:01:36,716> <INFO> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.DBEndpoint start> Kicked off 1 threads.
<2007-04-05 08:01:36,717> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> client acquired
<2007-04-05 08:01:36,719> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> begin transaction
<2007-04-05 08:01:36,721> <DEBUG> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.TopLinkLogger log> rollback transaction
<2007-04-05 08:01:36,722> <ERROR> <default.collaxa.cube.activation> <Database Adapter::Inbound> <oracle.tip.adapter.db.InboundWork handleException> Non retriable exception during polling of the database ORABPEL-11624
DBActivationSpec Polling Exception.
Query name: [initialCoordination], Descriptor name: [initialCoordination.AnotherTable]. Polling the database for events failed on this iteration.
If the cause is something like a database being down successful polling will resume once conditions change. Caused by Exception [TOPLINK-6024] (Oracle TopLink - 10g Release 3 (10.1.3.1.0) (Build 061004)): oracle.toplink.exceptions.QueryException
Exception Description: Modify queries require an object to modify.
Query: UpdateObjectQuery(null).
<2007-04-05 08:01:36,722> <FATAL> <default.collaxa.cube.activation> <AdapterFramework::Inbound> [initialCoordination_ptt::receive(AnotherTableCollection)]Resource Adapter requested Process shutdown!
<2007-04-05 08:01:36,723> <FATAL> <default.collaxa.cube.activation> <AdapterFramework::Inbound>
ORABPEL-11624
DBActivationSpec Polling Exception.
Query name: [initialCoordination], Descriptor name: [initialCoordination.AnotherTable]. Polling the database for events failed on this iteration.
If the cause is something like a database being down successful polling will resume once conditions change. Caused by Exception [TOPLINK-6024] (Oracle TopLink - 10g Release 3 (10.1.3.1.0) (Build 061004)): oracle.toplink.exceptions.QueryException
Exception Description: Modify queries require an object to modify.
Query: UpdateObjectQuery(null).
As reflected in the log messages, the process is automatically turned off. Turning it back on is ineffective, the server turns it back off with the same exception.
This is a separate issue, but I'm not seeing much reason for this to be happening either. I've scrapped the process and started over, using my own BPEL process that simulates what I would expect that the dbadapter is supposed to do when it's configured to poll for records.

ExecuteBatch commits despite autocommit(false)

Hello !
Can someone explain the jdbc-spec to me ?
Should executeBatch commit the transcations if no excpetion was
thrown ?
It seems that the oracle-driver does commit after executeBatch.
I don't think this is right (according to the jdbc-spec) and for us it
is really annoying since we wanted to use a temporary table
with "on commit delete rows". which has the effect, that the table
is empty after inserting with executeBatch (very clever).
The temporary table with "on commit preserve rows" works fine.
Thanks

it is my impression that if autocommit is set to false, and no con.rollback() was issued before the program exits, the drivers call an automatic con.commit() before it closes the connection(I've experienced this consistently with 4 different databases). But this probably is not in the java jdbc specs, but a driver implementation decision depending on the vendor/driver.
does anyone else know more on the specs?
Jamie

Select statement after Update statement under autocommit with RAC

Hi,
I've met a problem when developing my application with 10g RAC (3 machines). I am using open jdk 1.6.0 on linux platform with kernel release 2.6.18-128.e15PAE, my app using spring with oracledatasource to establish the database connection with autocommit. The situation as below:
my application sends SMPP requests and receives SMPP responses, when receiving SMPP responses, my app update the response details to related record in DB. For some concatenated messages, my app need to check whether all responses of the related concatenated message are received, if all received, my app update the final status of the message.
it is found that for some concatenated messages, all responses are received successfully, i.e. can be found in the database that the details of the responses are updated, however the final status of the message is not updated as expected. After further investigations to the database records and application logs, those cannot be updated with response returning almost at the same second, however they are manipulated one by one, not multi-thread. From the log of my app, it shown the dealing of the second response is started in the same second when the dealing of the first response is completed. It seems like when dealing the second response, it cannot "see" the first response is updated such that both responses find the message is not completed.
Wonder under what condition would this happen? my db config as below:
<bean id="dataSource" class="oracle.jdbc.pool.OracleDataSource" destroy-method="close">
<property name="driverType" value="oracle.jdbc.driver.OracleDriver" />
<property name="URL" value="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost1)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost2)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=dbhost3)(PORT=1521))(LOAD_BALANCE=yes)(CONNECT_DATA=(SERVICE_NAME=ha_bss)(SERVER=DEDICATED)))" />
<property name="user" value="dbuser" />
<property name="password" value="dbpassword" />
<property name="connectionCachingEnabled" value="true" />
<property name="connectionCacheProperties">
<props merge="default">
<prop key="InitialLimit">10</prop>
<prop key="MinLimit">10</prop>
<prop key="MaxLimit">2000</prop>
<prop key="AbandonedConnectionTimeout">0</prop>
<prop key="ConnectionWaitTimeout">120</prop>
<prop key="validate-connection">true</prop>
<prop key="validate-connection-statement">SELECT SYSDATE FROM DUAL</prop>
<prop key="factory-class">oracle.jdbc.pool.OracleDataSourceFactory</prop>
</props>
</property>
<property name="ONSConfiguration" value="nodes=dbhost1:6200,dbhost2:6200,dbhost3:6200"/>
<property name="fastConnectionFailoverEnabled" value="true"/>
</bean>
thanks

This is not likely to be a JDBC issue at all. It is likely that separate connections are being used
for the separate threads, and they may be to different RAC nodes. You must configure your
DBMS so there is zero latency between the nodes, else there may be some delay between
when one node changes data and another can see it.
HTH,
Joe

Hw to set the transaction autocommit interval in OCI

Could any one help me how to set the transaction autocommit interval for the specified database connection in OCI . The autocommit interval is the number of database write operations (inserts, deletes, and updates) to allow before forcing the underlying database to commit changes.
Babu

There is no 'autocommit' in OCI, it's up to the application to issue :
- OCITransCommit() explicitly
OR
- use mode=OCI_COMMIT_ON_SUCCESS when calling OCIStmtExecute()

Autocommit == false; close(); // what happens?

I'm currently writing a simple implementation of a DataSource which just wraps an exsiting Connection (Yeah, I know there are better ways for handling database connectivity - let's just say I'm forced to do so...).
I want to make sure that whenever I return the connection, autocommit is set to true, as defined by JDBC.
Now, suppose I have a previously used java.sql.Connection which autocommit value is set to false.
I wan't to set autocommit to true now, but this would commit data of a connection which, from a meta-point of view, is already closed. Obviously, I would execute a rollback at this point.
Okay, but maybe handling this autocommit stuff should be done when the connection is "closed", i.e. returned to my so-called pool. And here, I am not sure what to do. My point of view is to make a rollback also, but I'm not sure if this would be appropriate.
All applications I know just ask you what to do in such cases. But this is surely not the thing I can do here, and I don't know of any default behaviour for this.
So, does JDBC say anything about this scenario? I did not find anything related.
The commons DBCP (http://jakarta.apache.org/commons/dbcp/) seems to ignore this issue.
Thanks in advance,
Sebastian

Sir,
>
Noting of course that there is a specification for
JDBC and one would normally write to that, not the
java docs. Which is why I suggested using the spec.According to the JBDC 3.0 final spec section 10.1.1 page 62.
When auto-commit is disabled, each transaction must be explicitly
commited by calling the Connection method commit or else explicitly rolled back
by calling the Connection method rollback.Which adds a certain vagueness to the whole thing if taken out of context of the whole point of transactions. So the question is what should happen if neither is done explictly? The answer must be to rollback as a commit would violate the nature of a transactional system since none was specifically requested.
>
And I believe there is also one driver that
specifically does not do that. So relying on the
driver for the default behavior, what ever it should
be, probably isn't a good idea.If a driver or database does that IMO it is not a transactional database system or driver and certainly not one that follows the principles of ACID. If the database does that then I would be very wary of using transactions with the database. If the driver does that then I would get a new driver. May I ask what driver commits this horrible action on close?
Sincerely,
Slappy

ActiveStandby TwoSafe AutoCommit Mode

Chris,
Can ActiveStandby with TwoSafe replication work with default AutoCommit mode of TRUE ?
In one of the posts, you have mentioned that there is no way to set autocommit to false via configuration it has to be set during runtime via jdbc connection: connection.setAutoCommit(False).
If that is the case, does Oracle expects all applications, including non java, to programmatically set the autocommit to FALSE inorder to use TwoSafe replication? I am affraid, this fact is not documented in TimesTen documentation for 7.0
Could you please confirm above understandings.
Regards
VInod

I'm afraid that you are correct on all counts:
1. You cannot use 2-Safe replication with Autocommit TRUE.
2. You cannot 'configure' AUtocommit to be FALSE immediately after a connection.
3. All applications must set Autocommit OFF programatically if they wish to to not use Autocommit.
It is recognised that this can cause some issues and it may be that we will address this at some point.
Chris

Autocommit changing regions

Hi,
in normal cases it is really useful, automatic commit at changing regions.
Is there any possibility to prevent this autocommit and do commit manually when it is needed? (I.e. not at the first region even if there are changes)
Thank you for your help
Siegwin

As I understand, I can only change the session state of 1 item and not of the whole region. And: Which values can the session state have (where can I find this values - handbook?). Do you have an example setting session state?Sorry, I don't understand what you're saying here.
The information in the linked thread I was specifically referring to was:
Commits are performed when you explicitly issue them or when you alter session state with assignment statements, "select into" queries, or OUT variable assignments to bind-variable notated page- or application-item names or when you call apex_util.set_session_state. If you don't do any of that, no commits happen until the page processing completes.So if your
>
insert 1 record into the master table (single record form) DO NOT COMMIT!!
insert one or mor records to the child table (tabular form)
check for errors
>
processes do any of the above, i.e. something of the form
:APEX_ITEM := ...or
select ... into :APEX_ITEM from ...or
my_procedure(p_in => ..., p_out => :APEX_ITEM, ...);or
apex_util.set_session_state(...);then APEX will commit whilst maintaining session state.

AutoCommit Issue

Similar Messages

Maybe you are looking for