Is it a bug in OCI ?

We found a problem that once the database server was shut down or its network was disconnected, the connection to this database server would be blocked.
And any sql statements on this connection would hold on, and any cancel operations were unused.
Is this a bug in OCI ? Are there any timeout or other methods, oci functions or parameters to solve this problem?
Message was edited by:
user449258

This is connection timeout setting in Oracle Server (INIT files)

Similar Messages

Weblogic 6.1 sp5 core dump by OCI driver

I have encountered a core dump problem on weblogic server 6.1 SP5 the error message
as below, I am using weblogic oci driver for oracle "libweblogicoci37.so" , anyone
can help?
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 4 occurred at PC=0x242795c
Function name=(N/A)
Library=(N/A)
NOTE: We are unable to locate the function name symbol for the error
just occurred. Please refer to release documentation for possible
reason and solutions.

Galen Boyer wrote:
On Sun, 28 Mar 2004, [email protected] wrote:
Galen Boyer wrote:
On Sat, 27 Mar 2004, [email protected] wrote:
One way to get a substantial boost in reliability is to switch
to the latest appropriate Oracle thin driver.But then you can suffer performance losses.Actually, the latest oracle thin drivers are very fast. The 10g
driver in particular. Well, we are on 9i here and we have lots of CLOB and BLOB
operations. Understood. The latest should work. (How comfortable does that make you ;) )
It is a sad choice we used to have to make between
faster-but-buggy homicidal old OCI code (wherein a bug in one
module can cause a segfault in an innocent unrelated module's
execution, and bring down a whole JVM) and the reliability of
Java. Fortunately, the future is at hand. The future is at hand? I do believe you are starting to sound a
bit like an evangelist. :-)Yep. Back in '96 when we wrote and marketed all the first JDBC drivers
for MS SQLServer, Oracle, Informix and Sybase, we did it solely
so enable our application server to be able to do real work. We were all
absolutely sure the driver market would dry up in 6 months as all the
DBMS vendors made excellent free type-4 drivers. We were over-optimistic.
Sybase's driver still requires you to install non-standard tables and
procedures in the DBMS. Oracle drivers are sloutching toward sufficiency,
but their first GA driver had a hard-wired value of READ_UNCOMMITTED
for getTransactionIsolation, and if you tried setTransactionIsolation
of either READ_COMMITTED or SERIALIZABLE, the driver would throw an
exception! We actually had a weblogic workaround to intercept this
jdbc call and send the "ALTER SESSION " to do what the customer wanted!
At the same time we had a major struggle to get Oracle to admit that
in spite of their documentation, OCI was not threadsafe (killing our
OCI-based driver in weblogic applications) until 7.1.4 on solaris
and NT, and 8.0.5 on other platforms. Did you know they had separate
codelines for OCI on each platform? For a while each platform's OCI
had a different hard-wired limit of the number of simultaneous connections
on client could have? For a while that limited what our application server
could do. OCI was written for simple teller-like client applications.
The new thin drivers take on more of the possible client-side
processing, and can do RAC failover etc. JoeOh well. I for one am a bit skeptical that Oracle is going to
fix java driver bugs before OCI bugs and I don't have any reason
to commit to any "platform independent" solution like java's thin
driver. We are completely based on Oracle here and we have a
J2EE solution for the app just cause we had to choose something.
If thin is better, than we will go with that.The last highest-level talks I had with Oracle folks they indicated that
they wanted everyone to go thin. OCI was a headache for them. Their
OCI code was undocumented and all the original experts had left the company.
That was in 2000 or so, so it is likely better now. They may well have
invested a lot of reverse-documentation by now.
One of the benefits of Java is the reliability. I think you'll
ultimately be happier with the thin. We do want you successful.
Joe

Wls1211_generic.jar & wls_121200.jar & OCI

DriverManager.getConnection("jdbc:oracle:oci:@", info); work prefect on weblogic installed from(wls1211_generic.jar)!
But when i try run it under weblogic installed from wls_121200.jar it throw "java.lang.UnsatisfiedLinkError: no ocijdbc11 in java.library.path"
System.getProperty("java.library.path");
wls_121200.jar
wls1211_generic.jar
D:\app\product\112~1.0\client_1\BINBIN;
D:\app\product\11.2.0\client_1\BIN;
when I start weblogic(wls_121200.jar) with "-Djava.library.path=D:\app\product\11.2.0\client_1\BIN;" it throw "java.lang.UnsatisfiedLinkError ocijdbc11.dll: Can't find dependent libraries"
How to resolve this problem?
P.S. I am sorry for my english.

You can make your life much simpler and lose nothing if you were to use the JDBC driver in the 'thin' mode, not 'oci'.
The oci mode is not recommended for several reasons:
1 - There is a brittle one-to-one relationship between a given version of the JDBC driver jar, with a given version of
the Oracle OCI client libraries, so if you change the driver version (WLS versions have different driver versions),
then you would have to install the new/appropriate OCI libraries.
2 - Any bug in OCI native code can kill an entire JVM/weblogic server.
There is nothing nowadays that the driver operating in the thin mode cannot do, that it can do in the OCI mode,
and using it that way allows you to run or change among any multiple versions of the driver without concern,
as they run independently and are completely self-contained.

OCI Application with 1000 threads

Hi All,
I just created a simple OCI program which creates 500 threads (using OCIThreadCreate call) . The threads do nothing except sleeping for sometime and then exitting. After some threads are spawned (number very non-deterministic) the application aborts. The debugger say the segv was received in pthread_join indicating some problem in OCIThreadJoin. Anyone having seen similar issues and would like to share thought/suggestions here would be great. Amazingly, the application runs well with number of threads set to 301. If this number is increased to 302, thats when the application starts aborting. The machine I am using is a linux machine with a reasonably good configuration so I dont think number of processes etc could be an issue here.
Any inputs ? Bug in OCI ?
Thanks,
Sumit

Actually, there is quite a huge bug in my sample code (which also exists in the original post). There is no counter for the actual number of threads created. The reason the crash is happening on pthread_join (both naturally and beneath OCI) is because we're trying to join threads which haven't been created.
Corrected code, with a thread counter, resides below:
/* ========================================================================= */
/* -- INCLUSIONS ----------------------------------------------------------- */
/* ========================================================================= */
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include "oci.h"
#include "oratypes.h"
/* ========================================================================= */
/* -- DEFINITIONS ---------------------------------------------------------- */
/* ========================================================================= */
#define MAX_THREADS 1000
/* ========================================================================= */
/* -- GLOBALS -------------------------------------------------------------- */
/* ========================================================================= */
int last_created_thread = 0;
OCIEnv *envhp = (OCIEnv *) 0;
/* ========================================================================= */
/* -- LOCAL FUNCTIONS ------------------------------------------------------ */
/* ========================================================================= */
void
thread_func_oci (void *args)
    int p1 = (int) args;
    printf("Thread %d: Entering %s()\n", p1, __FUNCTION__);
    fflush(stdout);
    sleep(5);
    printf("Thread %d: Waiting %s()\n", p1, __FUNCTION__);
    fflush(stdout);
    sleep(5);
    printf("Thread %d: Exiting %s()\n", p1, __FUNCTION__);
    fflush(stdout);
void *
thread_func_pth (void *args)
    int p1 = (int) pthread_self();
    printf("Thread %d: Entering %s()\n", p1, __FUNCTION__);
    fflush(stdout);
    sleep(5);
    printf("Thread %d: Waiting %s()\n", p1, __FUNCTION__);
    fflush(stdout);
    sleep(5);
    printf("Thread %d: Exiting %s()\n", p1, __FUNCTION__);
    fflush(stdout);
    return NULL;
void
create_threads_oci (int num_threads)
    sword               status;
    OCIError           *errhp;
    OCIThreadId        *thr_id[MAX_THREADS];
    OCIThreadHandle    *thr_hp[MAX_THREADS];
    int                 j = 0;
    int                 arr[MAX_THREADS];
    /* Initialize our thread counter */
    last_created_thread = 0;
    status = OCIEnvCreate(&envhp, OCI_THREADED, 0, 0, 0, 0, 0, 0);
    if (status != OCI_SUCCESS)
        printf("Error EnvCreate\n");
        exit(1);
    status = OCIHandleAlloc(envhp, (void **) &errhp, OCI_HTYPE_ERROR, 0, 0);
    if (status != OCI_SUCCESS)
        printf("Could not create error handle \n");
        exit(1);
    status = OCIThreadInit(envhp, errhp);
    if (status != OCI_SUCCESS)
        printf("Error: ThreadInit");
    for (j = 0; j < num_threads; j++)
        status = OCIThreadIdInit(envhp, errhp, &thr_id[j]);
        OCIThreadHndInit((dvoid *) envhp, (OCIError *) errhp,
                         (OCIThreadHandle **) & (thr_hp[j]));
    for (j = 0; j < num_threads; j++)
        status = OCIThreadCreate((dvoid *) envhp, (OCIError *) errhp,
                                 thread_func_oci, (dvoid *) & (arr[j]),
                                 (OCIThreadId *) thr_id[j],
                                 (OCIThreadHandle *) thr_hp[j]);
        if (status != OCI_SUCCESS)
            printf("last_created_thread = %d :: j = %d\n", last_created_thread, j);
            fflush(stdout);
            break;
        else
            last_created_thread = j;
    for (j = 0; j <= last_created_thread; j++)
        status = OCIThreadJoin((dvoid *) envhp, (OCIError *) errhp,
                               (OCIThreadHandle *) thr_hp[j]);
        status = OCIThreadClose((dvoid *) envhp, (OCIError *) errhp,
                                (OCIThreadHandle *) thr_hp[j]);
        status = OCIThreadIdDestroy((dvoid *) envhp, (OCIError *) errhp,
                                    (OCIThreadId **) & (thr_id[j]));
        status = OCIThreadHndDestroy((dvoid *) envhp, (OCIError *) errhp,
                                     (OCIThreadHandle **) & (thr_hp[j]));
    status = OCIThreadTerm((dvoid *) envhp, (OCIError *) errhp);
void
create_threads_pth (int num_threads)
    int                 status;
    pthread_t           thr_hp[MAX_THREADS];
    int                 j = 0;
    /* Initialize our thread counter */
    last_created_thread = 0;
    for (j = 0; j < num_threads; j++)
        status = pthread_create(&thr_hp[j], NULL, thread_func_pth,
                                    (void *)(j));
        if (status != 0)
            printf("last_created_thread = %d :: j = %d\n", last_created_thread, j);
            fflush(stdout);
            break;
        else
            last_created_thread = j;
    for (j = 0; j <= last_created_thread; j++)
        pthread_join(thr_hp[j], NULL);
/* ========================================================================= */
/* -- EXTERNAL FUNCTIONS --------------------------------------------------- */
/* ========================================================================= */
int
main (int argc, char **argv)
    int num_threads = 0;
    printf("Threading Library Comparison Test\n");
    if (argc != 2)
        printf("Usage: %s n\n where n is no. of threads\n", argv[0]);
        exit(1);
    num_threads = atoi(argv[1]);
    if ((num_threads < 1) || (num_threads > MAX_THREADS))
        printf("The no of thread should between 1 and %u.\n", MAX_THREADS);
        exit(1);
    /* Launch POSIX Threads */
    create_threads_pth(num_threads);
    /* Launch OCI Threads */
    create_threads_oci(num_threads);
    return 0;
}

Oracle team members, this is Q for you...

Dear members of Oracle OLEDB team, you are the only one who can answer this (one page at oracle.com says that you are monitoring this forum):
ADO has Cancel method both on Command and Recordset object, which should cancel pending async call (every damn page on Internet says so). Oracle OCI interface has OCIBreak method that does exactly that. Now, why is Cancel method not working anything but waiting till the async call execution is fully completed (the call to Cancel method really blocks the calling thread!!) - it does not cancel anything, it just blocks the code !
I can expect that Microsoft didn't bother about this "insignificant" issue, but this is Oracle provider for Oracle server written by Oracle... - why is your provider behaving the same ?
I expect you to reply with really good explanation to this quite important issue, this is not a hundredth-time-"how to retrieve recordset from a stored procedure"-beginners-question
Thanks in advance.
P.S.
Please don't misunderstand, fetching is not a problem, only "heavy" command execution ("heavy" select statement in my case)

There was, in the early 8.1.7 days at least, a bug in OCI where the break/ cancel call didn't work properly. I have no idea whether it was fixed or not and I've long since forgotten the number. You may be able to find it on metalink. You don't say what version of the client you have or whether you've installed any patchsets for the client. If you're not on the latest patchset for your platform, and your platform isn't at least 8.1.7, I'd strongly suggest upgrading.
Note that as a general rule, these forums aren't monitored by Oracle developers. From time to time they'll pop by, but it's not something that's likely to be their #1 priority. You could log a TAR on metalink to get an answer from an Oracle person.
Justin

Non Blocking Call with OCCI

Hi Everyone
I have searched through the whole OCCI documentation and could not find a way to make an asynchronous call to the database. you see the issue we have is that we need to cancel a call to the database if it does not return within the timeout value set. However, OCI does have the cancelling mechanism, but we have doned some testing and the Binding and Defining parameters call take to much of memory and and CPU. Once in a while it runs out of memory.
Has any body come across this problem, and what solutions do you have i mind

andyman35uk wrote:
This doesn't seem to work under 10g. Both getOCIServer and getOCIServiceContext seem to return invalid handles.
See Oracle Bug 3616743 - Oci Svcctx Handle Derived From Occi Connection Class Is Invalid
The invalid handle was most likely the error handle, not the service context nor server handles as kmohan indicated above. The error handle needs to be allocated first.
For reference:
OCIError *errhp;
OCIHandleAlloc((dvoid *)e, (dvoid **)&errhp, (ub4)OCI_HTYPE_ERROR, (size_t)0, (dvoid **)0);
OCISvcCtx s = ((Connection )c)->getOCIServiceContext();
sword r = OCIBreak(s, errhp);
// check r and errhp for errors before reusing them
r = OCIReset(s, errhp);
// check r and errhp for errors
OCIHandleFree((dvoid *)errhp, (ub4)OCI_HTYPE_ERROR);

OCIStmtExecute returns OCI_SUCCESS for NON_BLOCKING_MODE

Hello all,
I would like to know if anybody has ever encountered this problem. I executed a OCIStmtExecute in NON BLOCKING MODE,
While looping to check the status on OCIStmtExecute, I noticed that OCIStmtExecute
returned OCI_SUCCESS while actually it is not. I captured the error code using OCIErrorGet and
I still get OCI_STILL_EXECUTING (errocode = 3123).
What OCIStmtExecute returning is not the same as the actual error code in Error Handle.
Is it a bug in OCI ?
The following is the sample code that I used to check OCIStmtExecute:
/* set NON Blocking Mode */
ret_no = ppf_oci_checkerr(Errhp, OCIAttrSet((dvoid *) Srvhp,
(ub4) OCI_HTYPE_SERVER, (dvoid *) 0,
(ub4) 0, (ub4) OCI_ATTR_NONBLOCKING_MODE, Errhp), err);
CHECK_OCI_RESULT(ret_no, "OCIAttrSet", err);
ret_no = OCIStmtExecute(Svchp, Stmthp, Errhp, (ub4) 1, (ub4) 0,
(CONST OCISnapshot *) NULL, (OCISnapshot *) NULL,
OCI_COMMIT_ON_SUCCESS);
OCIErrorGet((dvoid *)Errhp, (ub4) 1, (text *) NULL,
&errorcode, errbuff, (ub4) 512,
OCI_HTYPE_ERROR);
while(((errorcode) == abs(OCI_STILL_EXECUTING)) &&
(duration < PPF_OCI_TRANSACTION_TIMER))
finish = time(0);
ret_no = OCIStmtExecute(Svchp, Stmthp, Errhp, (ub4) 1, (ub4) 0,
(CONST OCISnapshot *) NULL, (OCISnapshot *) NULL,
OCI_COMMIT_ON_SUCCESS);
printf("return no:%d - absolute: %d - OCISTILL:%d\n", ret_no, abs(errorcode), OCI_STILL_EXECUTING);
OCIErrorGet((dvoid *)Errhp, (ub4) 1, (text *) NULL,
&errorcode, errbuff, (ub4) 512,
OCI_HTYPE_ERROR);
duration = difftime(finish, start);
printf("*");
The following is the sample output:
*return no:-3123 - absolute: 3123 - OCISTILL:-3123
*return no:-3123 - absolute: 3123 - OCISTILL:-3123
*return no:-3123 - absolute: 3123 - OCISTILL:-3123
*return no:0 - absolute: 3123 - OCISTILL:-3123
*return no:-3123 - absolute: 3123 - OCISTILL:-3123
*return no:-3123 - absolute: 3123 - OCISTILL:-3123
Thanks,
Suryadi

OK, sorry about the delay, but this is a long post :)
First, if you use separate environment handles for each connection, you should not need OCI_THREADED.
Second, while NPTL and LinuxThreads could cause an issue, I doubt it.
Third, if you're still having an issue when you're using blocking mode, it seems like it's either an Apache issue or another issue within your code. When it segfaults, does it dump core? Can you backtrace it to see where it crashed? If not, you could always add a handler for it.
Sorry about the short answer, but there are a lot of variables involved (Apache, OCI, multithreading, and your app).

BEA recommendation for use of Thin or Thick driver of Oracle 10g

What is recommended by BEA to use Oracle Thin or thick driver for connecting to oracle 10g database from Weblogic Server 8.1.5?

nmyneni wrote:
What is recommended by BEA to use Oracle Thin or thick driver for connecting to oracle 10g database from Weblogic Server 8.1.5?Use the Oracle driver in the thin mode, not the thick/OCI mode.
The latter will expose you to native code bugs in OCI that
can kill an entire JVM.

A favor to ask of any C-OCI programmer to prove a DBMS bug....

I am looking for someone good and kind enough to write a C+OCI
program that does this trivial thing:
Make a connection, prepare a statement for execution, with no
parameters, simply to execute "TRUNCATE TABLE MYTABLE".
Then the program should execute the statement. Then, it should
print out to stdout "TRUNCATED MYTABLE. Press <enter> to repeat",
and read stdin until it gets the newline, and then executes the
statement again.
This program will demonstrate the failure of the DBMS-client
contract. The user will start a SQL-PLUS session and create
that table, and insert rows (and commit). Then, in another
window, the user will start this C program, which will truncate
the table, and wait for further input. Then the user will verify
from SQL-plus that the table has been truncated. Then the
user use SQL-PLUS to add more rows to the table, and commit.
Then the user will press <ENTER> at the C program, making it
re-execute the TRUNCATE statement (apparently successfully)
and exit. The user should then see in SQL-PLUS that the second
batch of rows are still there.
Joe

Hi Joe,
I'm not sure I would call this a database bug, rather it seems more like a documentation bug/omission. In fact, the issue is correctly identified in the 11g OCI docs for the OCIStmtPrepare function:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/oci17msc001.htm#i575144
In particular:
Before re-executing a DDL statement, call this function a second time.
It looks like the designed behavior is to ignore subsequent invocations of DDL without calling OCIStmtPrepare as a server round-trip does not appear to take place. So what you are seeing may not be the desired behavior, but it appears to be the expected behavior.
For example, a tkprof of the scenario you describe shows:
truncate table mytable
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.01          0         57         13           0
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.01          0         57         13           0Having said that, here's a (very) basic bit of OCI code to illustrate this...
DISCLAIMER(s): I am not an OCI programmer. I am a DBA and I sometimes live in the .NET world. This is very basic and contains bad practices such as hard-coding and no error checking.
#ifdef WIN32
#define _CRT_SECURE_NO_DEPRECATE 1
#endif
#include <stdio.h>
#include <string.h>
#include <oci.h>
int main (int argc, char *argv[])
OCIEnv      *envhp = NULL; /* OCI Environment handle     */
OCIError    *errhp = NULL; /* OCI Error handle           */
OCISvcCtx   *svchp = NULL; /* OCI Service Context handle */
OCIServer   *srvhp = NULL; /* OCI Server handle          */
OCISession *usrhp = NULL; /* OCI User Session handle    */
OCIStmt     *stmtp = NULL; /* OCI Statement handle       */
/* connection information */
oratext *username = "scott";
oratext *password = "tiger";
oratext *database = "otndemo";
/* the sql statement to execute */
oratext *sqlstmt = "truncate table mytable";
/* used to hold the results of each OCI call */
sword result = 0;
/* used to hold input */
char buf[80];
/* Initialize and create a default environment */
result = OCIEnvCreate(&envhp, OCI_DEFAULT, (void *) 0, 0, 0, 0, (size_t) 0, (void **) 0);
/* allocate an error handle */
result = OCIHandleAlloc((void *) envhp, (void **) &errhp, OCI_HTYPE_ERROR, 0, (void **) 0);
/* allocate a service context handle */
result = OCIHandleAlloc((void *) envhp, (void **) &svchp, OCI_HTYPE_SVCCTX, 0, (void **) 0);
/* allocate a server handle */
result = OCIHandleAlloc((void *) envhp, (void **) &srvhp, OCI_HTYPE_SERVER, 0, (void **) 0);
/* allocate a user session handle */
result = OCIHandleAlloc((void *) envhp, (void **) &usrhp, OCI_HTYPE_SESSION, 0, (void **) 0);
/* set user name attribute in user session handle */
result = OCIAttrSet((void *) usrhp, OCI_HTYPE_SESSION, (void *) username, (ub4) strlen(username), OCI_ATTR_USERNAME, errhp);
/* set password attribute in user session handle */
result = OCIAttrSet((void *) usrhp, OCI_HTYPE_SESSION, (void *) password, (ub4) strlen(password), OCI_ATTR_PASSWORD, errhp);
/* create a server context using the specified database */
result = OCIServerAttach(srvhp, errhp, database , (sb4) strlen(database), OCI_DEFAULT);
/* set the server attribute in the service context handle */
result = OCIAttrSet((void *) svchp, OCI_HTYPE_SVCCTX, (void *) srvhp, (ub4) 0, OCI_ATTR_SERVER, errhp);
/* open the session with the database */
result = OCISessionBegin(svchp, errhp, usrhp, OCI_CRED_RDBMS, OCI_DEFAULT);
/* set the user session attribute in the service context handle */
result = OCIAttrSet((void *) svchp, OCI_HTYPE_SVCCTX, (void *) usrhp, (ub4) 0, OCI_ATTR_SESSION, errhp);
/* allocate the statement handle */
result = OCIHandleAlloc((void *) envhp, (void **) &stmtp, OCI_HTYPE_STMT, 0, (void **) 0);
/* prepare the statement for execution */
result = OCIStmtPrepare(stmtp, errhp, sqlstmt, (ub4) strlen((char *) sqlstmt), OCI_NTV_SYNTAX, OCI_DEFAULT);
/* execute the statement */
result = OCIStmtExecute(svchp, stmtp, errhp, (ub4) 1, (ub4) 0, (CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT);
/* print prompt line to console window */
(void) printf("TRUNCATED MYTABLE. Press <enter> to repeat ");
/* not safe, but as this is a controlled test, it is a known item */
(void) gets(buf);
/* NOTE: preparing the statement again is required for DDL to work correctly */
/* comment the following line to illustrate that ddl is not re-executed */
result = OCIStmtPrepare(stmtp, errhp, sqlstmt, (ub4) strlen((char *) sqlstmt), OCI_NTV_SYNTAX, OCI_DEFAULT);
/* execute the statement again */
result = OCIStmtExecute(svchp, stmtp, errhp, (ub4) 1, (ub4) 0, (CONST OCISnapshot *) NULL, (OCISnapshot *) NULL, OCI_DEFAULT);
/* free statement handle */
result = OCIHandleFree((void *) stmtp, OCI_HTYPE_STMT);
/* terminate the session with the database */
result = OCISessionEnd(svchp, errhp, usrhp, OCI_DEFAULT);
/* detach from the server */
result = OCIServerDetach(srvhp, errhp, OCI_DEFAULT);
/* deallocate the environment handle     */
/* OCI will deallocate the child handles */
result = OCIHandleFree((void *) envhp, OCI_HTYPE_ENV);
return OCI_SUCCESS;
}Perhaps Jonah or Prajith will also see this thread and have a comment. They are both more well-versed in OCI than I...
Regards,
Mark
[EDIT]
Small edit for clarification on documentation link.

BUG: retrieving NCHAR value using ViewObject returns "???" with OCI driver

Hi,
after upgrading JDeveloper to 10.1.3.1 we cannot use OCI JDBC drivers, because they don't work correctly - characters, that do not exist in database character set (EE8ISO8859P2 in our case) are converted to "?". Thin driver works well. We need to use OCI, because we had some issues with RAC with thin driver.
Test case is easy: create table with NCHAR column, populate with unicode data, create ViewObject to select from this table and it will work only with THIN and not with OCI driver. This worked well with 10.1.3.0. When I tried to directly connect to DB and select that table using java.sql.Statement, it worked with both drivers, that's why I suspect the mechanics inside ADF BC.
I logged a SR for this in Metalink, but try this way as well, for someone else could hit the same problem.
Thanks for any help,
Viliam

Hi,
after upgrading JDeveloper to 10.1.3.1 we cannot use OCI JDBC drivers, because they don't work correctly - characters, that do not exist in database character set (EE8ISO8859P2 in our case) are converted to "?". Thin driver works well. We need to use OCI, because we had some issues with RAC with thin driver.
Test case is easy: create table with NCHAR column, populate with unicode data, create ViewObject to select from this table and it will work only with THIN and not with OCI driver. This worked well with 10.1.3.0. When I tried to directly connect to DB and select that table using java.sql.Statement, it worked with both drivers, that's why I suspect the mechanics inside ADF BC.
I logged a SR for this in Metalink, but try this way as well, for someone else could hit the same problem.
Thanks for any help,
Viliam

What is the diffrence between OCI and OCCI?

What is the diffrence between OCI and OCCI?

Will Lee wrote:
What is the diffrence between OCI and OCCI?Beside the other answers, there are a few additional points to consider:
1) OCI is the "gold" standard API. New stuff is always available in OCI first, and only later trickles down to other APIs, like OCCI.
2) OCI is a low-level API, harder to get started with, than OCCI. APIs in OCI are often "untyped", taking a void*, which opens the door for errors.
3) In OCCI you set values, while in OCI you bind them. So OCCI takes a copy of your values, while OCI takes an address at which to later read the value. This opens the door to subtle bugs where you pass the address of a temporary in OCI, which later crashes in some mysterious ways. So OCCI is way safer in this regard.
4) OCI is C code, which is very portable. Because OCCI is C++ code, and on Windows you can't easily mix and match libraries compiled with different versions of Visual C++ (VC6, 7, 8, 9), you have to wait for Oracle to make a new build with the latest MS compiler. Just see the number of questions on this OCI forum and the OCCI one.
5) OCI is used internally by Oracle to write many of their own tools, it's the lingua franca between the Core DB group and the other groups. Since they use it themselves, it's much more stable that OCCI, which is mostly only used by outside customers.
6) The way SQL objects are dealt with in OCI and OCCI is fundamentally different, to the point where you can't mix and match OCCI and OCI object calls.
#1 above is one reason we had to abandon using OCCI, lacked support for the new in 11g BinaryXML, but that's just one example.
IMHO OCI is the way to go, if you want the latest and greatest. Yes, it's more difficult to code against, so the learning curve is steeper, but once you've reached critical mass it's just fine. If you write code in C++ as opposed to C, you can easily make it a lot safer with a thin C++ layer on top which, unlike OCCI, still allows you access any OCI raw handle to do stuff the wrappers don't expose. My $0.02 ;-) --DD

Getting DRG-50858: OCI error: OCI_NO_DATA with user_datastore on 9iR2

Hi there,
Created a procedure and mapped it to a user_datastore... getting the following error in the ctx error table:
DRG-12604: execution of user datastore procedure has failed
DRG-50857: oracle error in drsinopen
DRG-50858: OCI error: OCI_NO_DATA
Created the following preferences:
begin
-- set the user datastore procedure
ctx_ddl.create_preference('ccnews_ud', 'user_datastore');
ctx_ddl.set_attribute('ccnews_ud', 'procedure', 'ctxsys_ccnews_ustore_idx_prc');
ctx_ddl.set_attribute('ccnews_ud', 'output_type', 'CLOB');
ctx_ddl.create_preference('english_lexer','basic_lexer');
ctx_ddl.create_preference('french_lexer','basic_lexer');
ctx_ddl.create_preference('global_lexer', 'multi_lexer');
ctx_ddl.add_sub_lexer('global_lexer','default','english_lexer');
ctx_ddl.add_sub_lexer('global_lexer','ENGLISH','english_lexer','1');
ctx_ddl.add_sub_lexer('global_lexer','FRENCH','french_lexer','2');
end;
Is it possible that the procedure returns an empty clob for a row which causes this problem?
The index is running on a table with 28,000 rows, I have to admint that the data integrity is not up to par (ie could be existence of orphaned records) Could this cause the problem?

An empty clob or even an orphaned record should not cause the problem. It is usually due to a bug in the procedure. Data corruption could be a cause. Please post a copy and paste of a run of create or replace for your procedure, followed by show errors and a copy and paste of a run of a query that produces the error stack.

Bug in Oracle JDBC Pooling Classes - Deadlock

We are utilizing Oracle's connection caching (drivers 10.2.0.1) and have found a deadlock situation. I reviewed the code for the (drivers 10.2.0.3) and I see the same problem could happen.
I searched and have not found this problem identified anywhere. Is this something I should post to Oracle in some way (i.e. Metalink?) or is there a better forum to get this resolved?
We are utilizing an OCI driver with the following setup in the server.xml
<ResourceParams name="cmf_toolbox">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>hidden</value>
</parameter>
<parameter>
<name>password</name>
<value>hidden</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:oci:@PTB2</value>
</parameter>
<parameter>
<name>connectionCachingEnabled</name>
<value>true</value>
</parameter>
<parameter>
<name>connectionCacheProperties</name>
<value>(InitialLimit=5,MinLimit=15,MaxLimit=75,ConnectionWaitTimeout=30,InactivityTimeout=300,AbandonedConnectionTimeout=300,ValidateConnection=false)</value>
</parameter>
</ResourceParams>
We get a deadlock situation between two threads and the exact steps are this:
1) thread1 - The OracleImplicitConnectionClassThread class is executing the runAbandonedTimeout method which will lock the OracleImplicitConnectionCache class with a synchronized block. It will then go thru additional steps and finally try to call the LogicalConnection.close method which is already locked by thread2
2) thread2 - This thread is doing a standard .close() on the Logical Connection and when it does this it obtains a lock on the LogicalConnection class. This thread then goes through additional steps till it gets to a point in the OracleImplicitConnectionCache class where it executes the reusePooledConnection method. This method is synchronized.
Actual steps that cause deadlock:
1) thread1 locks OracleImplicitConnectionClass in runAbandonedTimeout method
2) thread2 locks LogicalConnection class in close function.
3) thread1 tries to lock the LogicalConnection and is unable to do this, waits for lock
4) thread2 tries to lock the OracleImplicitConnectionClass and waits for lock.
***DEADLOCK***
Thread Dumps from two threads listed above
thread1
Thread Name : Thread-1 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x30267fe8 Waiting for Monitor Lock on 0x509190d8 Java Stack at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - waiting to lock 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at oracle.jdbc.pool.OracleImplicitConnectionCache.closeCheckedOutConnection(OracleImplicitConnectionCache.java:1330) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.runAbandonedTimeout(OracleImplicitConnectionCacheThread.java:261) - locked 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.run(OracleImplicitConnectionCacheThread.java:81)
thread2
Thread Name : http-7320-Processor83 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x509190d8 Waiting for Monitor Lock on 0x30267fe8 Java Stack at oracle.jdbc.pool.OracleImplicitConnectionCache.reusePooledConnection(OracleImplicitConnectionCache.java:1608) - waiting to lock 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleConnectionCacheEventListener.connectionClosed(OracleConnectionCacheEventListener.java:71) - locked 0x34d514f8> (a oracle.jdbc.pool.OracleConnectionCacheEventListener) at oracle.jdbc.pool.OraclePooledConnection.callImplicitCacheListener(OraclePooledConnection.java:544) at oracle.jdbc.pool.OraclePooledConnection.logicalCloseForImplicitConnectionCache(OraclePooledConnection.java:459) at oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:475) at oracle.jdbc.driver.LogicalConnection.closeInternal(LogicalConnection.java:243) at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - locked 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at com.schoolspecialty.cmf.yantra.OrderDB.updateOrder(OrderDB.java:2022) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:119) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:67) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.UpdateCartAction.perform(Unknown Source) at com.schoolspecialty.mvc2.ActionServlet.doPost(ActionServlet.java:112) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPostOrGet(Unknown Source) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at com.schoolspecialty.ecommerce.servlets.filters.EcommerceURLFilter.doFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)

We used a documented option to abandon connects in the case of an unforeseen error. The consequence of using this option was not a graceful degradation in performance but a complete lockup of the application. The scenario in which we created a moderate number of abandoned connections was a rare error scenario but a valid test.
How could this not be a bug in the Oracle driver? Is dead-lock a desireable outcome of using an option? Is dead-lock ever an acceptable consequence of using a feature as documented?
Turns out other Oracle options to recover from an unexpected error also incur a similar deadlock (TimeToLiveTimeout).
I did a code review of the decompiled drivers and it clearly shows the issue, confirming the original report of this issue. Perhaps you have evidence to the contrary or better evidence to support your statement "not a bug in Oracle"?
Perhaps you are one of the very few people who have not experience problems with Oracle drivers? I've been using Oracle since 7.3.4 and it seems that I have always been working around Oracle JDBC driver problems.
We are using Tomcat with the OracleDataSourceFactory.

A Bug in 11.1 array interface

I have just encounter some code that runs fine in Oracle 9 to 10 but in 11.1 I am getting a different result.
basically I have this SQL
"INSERT INTO $table ( row_1, row_2, row_3) VALUES (?,?,?)"
and bind all three to this array
@var2 = (2,2,2,2,'s',2,2,2,2,2);
using OCIBindByName and OCIBindDynamic and then execute them with
OCIStmtExecute, with a mode (IN)
of OCI_BATCH_ERRORS OCI_COMMIT_ON_SUCCESS (or 160)
what happens is the commit does not happen in 11 but does happen in 9~10?
Did something change in the execute in 11 or should I raise this up to a bug status??

Ok here is a trace of the OCI Calls I use, and yes I the last one I give is a OCITransCommit
st_execute_array INSERT count=10 (ARRAY(0x1a725c8) ARRAY(0x1a934c4) undef)
OCIBindByName(876dad8,19cab00,8755e68,":p1",3,0,1,1,0,0,0,0,0,DATA_AT_EXEC)=SUCCESS
OCIBindDynamic(876eda8,8755e68,19caadc, phs_in,19caadc,phs_out)=SUCCESS
OCIBindByName(876dad8,1a27810,8755e68,":p2",3,0,1,1,0,0,0,0,0,DATA_AT_EXEC)=SUCCESS
OCIBindDynamic(876ec68,8755e68,1a277ec,phs_in,1a277ec,phs_out)=SUCCESS
OCIBindByName(876dad8,1a2bc18,8755e68,":p3",3,0,1,1,0,0,0,0,0,DATA_AT_EXEC)=SUCCESS
OCIBindDynamic(876eb28,8755e68,1a2bbf4,phs_in,1a2bbf4,phs_out)=SUCCESS
OCIStmtExecute(8755db0,876dad8,8755e68,10,0,0,0,160)=SUCCESS_WITH_INFO ->(OCI_BATCH_ERRORS|OCI_COMMIT_ON_SUCCESS)<--
OCIAttrGet(876dad8,OCI_HTYPE_STMT,140f4ec,0,129,8755e68)=SUCCESS
OCIErrorGet(8755e68,1,"<NULL>",140f48c,"ORA-24381: error(s) in array DML",1024,2)=SUCCESS
OCIErrorGet(8755e68,2,"<NULL>",140f48c,"ORA-24381: error(s) in array DML",1024,2)=NO_DATA
OCIAttrGet(876dad8,OCI_HTYPE_STMT,140f55c,0,73,8755e68)=SUCCESS
st_execute_array 1 errors in batch.
OCIHandleAlloc(8727940,140f578,OCI_HTYPE_ERROR,0,0)=SUCCESS
OCIHandleAlloc(8727940,140f570,OCI_HTYPE_ERROR,0,0)=SUCCESS
OCIParamGet(8755e68,2,876c3c0,140f578,0)=SUCCESS
OCIAttrGet(876c968,OCI_HTYPE_ERROR,140f550,0,74,8755e68)=SUCCESS
st_execute_array error in row 4.
OCIErrorGet(876c968,1,"<NULL>",140f4cc,"ORA-01722: invalid number",1024,2)=SUCCESS
     OCIErrorGet(876c968,2,"<NULL>",140f4cc,"ORA-01722: invalid number",1024,2)=NO_DATA
OCIHandleFree(876c3c0,OCI_HTYPE_ERROR)=SUCCESS
OCIHandleFree(876c968,OCI_HTYPE_ERROR)=SUCCESS
OCITransCommit(8755db0,8755e68,0)=SUCCESS
st_execute_array warning: ORA-24381: error(s) in array DML (SUCCESS_WITH_
INFO: error possibly near <*> indicator at char 56 in 'INSERT INTO test_ea( row_1, row_2,
row_3) VALUES (:p1,:<*>p2,:p3)') [for Statement "INSERT INTO test_ea( row_1, row_2, row_
3) VALUES (?,?,?)"]
and here is the code snipits but it is take out of a larger program so I will not run
sb4
phs_in(dvoid octxp, OCIBind bindp, ub4 iter, ub4 index,
     dvoid **bufpp, ub4 alenp, ub1 piecep, dvoid **indpp)
     phs_t phs = (phs_t)octxp;
STRLEN phs_len;
AV *tuples_av;
     SV *sv;
     AV *av;
     SV **sv_p;
     /* Check for bind values supplied by tuple array. */
     tuples_av = phs->imp_sth->bind_tuples;
     if(tuples_av) {
          /* NOTE: we already checked the validity in ora_st_bind_for_array_exec(). */
          sv_p = av_fetch(tuples_av, phs->imp_sth->rowwise ? (int)iter : phs->idx, 0);
          av = (AV*)SvRV(*sv_p);
          sv_p = av_fetch(av, phs->imp_sth->rowwise ? phs->idx : (int)iter, 0);
          sv = *sv_p;
          if(SvOK(sv)) {
          *bufpp = SvPV(sv, phs_len);
          phs->alen = (phs->alen_incnull) ? phs_len+1 : phs_len;
          phs->indp = 0;
          } else {
          *bufpp = SvPVX(sv);
          phs->alen = 0;
          phs->indp = -1;
*alenp = phs->alen;
*indpp = &phs->indp;
*piecep = OCI_ONE_PIECE;
if (!tuples_av && (index > 0 || iter > 0))
          croak(" Arrays and multiple iterations not currently supported (in %d/%d)", index,iter);
return OCI_CONTINUE;
sb4
phs_out(dvoid octxp, OCIBind bindp,
     ub4 iter,     /* execution itteration (0...)     */
     ub4 index,     /* array index (0..)          */
     dvoid **bufpp,     /* A pointer to a buffer to write the bind value/piece.     */
     ub4 **alenpp,     /* A pointer to a storage for OCI to fill in the size     */
               /* of the bind value/piece after it has been read.     */
     ub1 piecep,     / */
     dvoid **indpp,     /* Return a pointer to contain the indicator value which either an sb2     */
               /* value or a pointer to an indicator structure for named data types.     */
     ub2 **rcodepp)     /* Returns a pointer to contains the return code.     */
phs_t phs = (phs_t)octxp;     /* context */
if (phs->desc_h) { /* a descriptor if present (LOBs etc)*/
          *bufpp = phs->desc_h;
          phs->alen = 0;
} else {
          SV *sv = phs->sv;
          if (SvTYPE(sv) == SVt_RV && SvTYPE(SvRV(sv)) == SVt_PVAV) {
          sv = av_fetch((AV)SvRV(sv), (IV)iter, 1);
          if (!SvOK(sv))
                    sv_setpv(sv,"");
          bufpp = SvGROW(sv, (size_t)(((phs->maxlen < 28) ? 28 : phs->maxlen)+1)/for null*/);
          phs->alen = SvLEN(sv);     /* max buffer size now, actual data len later */
*alenpp = &phs->alen;
*indpp = &phs->indp;
*rcodepp= &phs->arcode;
*piecep = OCI_ONE_PIECE;
return OCI_CONTINUE;
static int
do_bind_array_exec(sth, imp_sth, phs)
SV *sth;
imp_sth_t *imp_sth;
phs_t *phs;
     dTHX;
sword status;
OCIBindByName_log(imp_sth->stmhp, &phs->bndhp, imp_sth->errhp,
(text*)phs->name, (sb4)strlen(phs->name),
0,
phs->maxlen ? (sb4)phs->maxlen : 1, /* else bind "" fails */
(ub2)phs->ftype, 0,
NULL, /* ub2 alen_ptr not needed with OCIBindDynamic /
0,
0, /* max elements that can fit in allocated array */
NULL, /* (ptr to) current number of elements in array */
(ub4)OCI_DATA_AT_EXEC,
status);
if (status != OCI_SUCCESS) {
oci_error(sth, imp_sth->errhp, status, "OCIBindByName");
return 0;
OCIBindDynamic_log(phs->bndhp, imp_sth->errhp,
(dvoid *)phs, phs_in,
(dvoid *)phs, phs_out, status);
if (status != OCI_SUCCESS) {
oci_error(sth, imp_sth->errhp, status, "OCIBindDynamic");
return 0;
return 1;
static void
init_bind_for_array_exec(phs)
phs_t *phs;
     dTHX;
if (phs->sv == &sv_undef) { /* first bind for this placeholder */
phs->is_inout = 0;
phs->maxlen = 1;
/* treat Oracle7 SQLT_CUR as SQLT_RSET for Oracle8 */
if (phs->ftype==102)
phs->ftype = 116;
/* some types require the trailing null included in the length. */
/* SQLT_STR=5=STRING, SQLT_AVC=97=VARCHAR */
phs->alen_incnull = (phs->ftype==SQLT_STR || phs->ftype==SQLT_AVC);
int
st_execute_array(sth, imp_sth, tuples, tuples_status, columns, exe_count)
SV *sth;
imp_sth_t *imp_sth;
SV *tuples;
SV *tuples_status;
SV *columns;
ub4 exe_count;
     sword status, exe_status;
int is_select = (imp_sth->stmt_type == OCI_STMT_SELECT);
AV tuples_av, tuples_status_av, *columns_av;
ub4 oci_mode;
ub4 num_errs;
int i,j;
int autocommit = 1;
SV **sv_p;
     phs_t **phs;
     SV *sv;
     AV *av;
int param_count;
char namebuf[30];
STRLEN len;
int outparams = (imp_sth->out_params_av) ? AvFILL(imp_sth->out_params_av)+1 : 0;
tuples_av = (AV*)SvRV(tuples);
/* Check the `columns' parameter. */
if(SvTRUE(columns)) {
if(!SvROK(columns) || SvTYPE(SvRV(columns)) != SVt_PVAV) {
croak("ora_st_execute_array(): columns not an array peference.");
columns_av = (AV*)SvRV(columns);
} else {
columns_av = NULL;
/* Check the `tuples_status' parameter. */
if(SvTRUE(tuples_status)) {
if(!SvROK(tuples_status) || SvTYPE(SvRV(tuples_status)) != SVt_PVAV) {
     croak("ora_st_execute_array(): tuples_status not an array reference.");
tuples_status_av = (AV*)SvRV(tuples_status);
av_fill(tuples_status_av, exe_count - 1);
/* Fill in 'unknown' exe count in every element (know not how to get
individual execute row counts from OCI). */
for(i = 0; (unsigned int) i < exe_count; i++) {
av_store(tuples_status_av, i, newSViv((IV)-1));
} else {
tuples_status_av = NULL;
/* Nothing to do if no tuples. */
if(exe_count <= 0)
return 0;
param_count=c_NUM_PARAMS(imp_sth);/*returns the # of parameters on the imp_sth struct*/
     phs = safemalloc(param_count*sizeof(*phs));
memset(phs, 0, param_count*sizeof(*phs));
     for(j = 0; (unsigned int) j < exe_count; j++) {
     sv_p = av_fetch(tuples_av, j, 0);
if(sv_p == NULL) {
Safefree(phs);
croak("Cannot fetch tuple %d", j);
sv = *sv_p;
if(!SvROK(sv) || SvTYPE(SvRV(sv)) != SVt_PVAV) {
Safefree(phs);
croak("Not an array ref in element %d", j);
av = (AV*)SvRV(sv);
for(i = 0; i < param_count; i++) {
if(!phs) {
SV **phs_svp;
sprintf(namebuf, ":p%d", i+1);
phs_svp = hv_fetch(imp_sth->all_params_hv,
namebuf, strlen(namebuf), 0);
if (phs_svp == NULL) {
Safefree(phs);
croak("Can't execute for non-existent placeholder :%d", i);
phs[i] = (phs_t*)(void*)SvPVX(*phs_svp); /* placeholder struct */
if(phs[i]->idx < 0) {
Safefree(phs);
croak("Placeholder %d not of ?/:1 type", i);
init_bind_for_array_exec(phs[i]); /*bind the value */
sv_p = av_fetch(av, phs[i]->idx, 0);
if(sv_p == NULL) {
Safefree(phs);
croak("Cannot fetch value for param %d in entry %d", i, j);
               sv = *sv_p;
     /*check to see if value sv is a null (undef) if it is upgrade it*/
               if (!SvOK(sv))     {
                    if(SvUPGRADE(sv, SVt_PV)){} /* For GCC not to warn on unused result */
               else {
          SvPV(sv, len);
     /* Find the value length, and increase maxlen if needed. */
     if(SvROK(sv)) {
     Safefree(phs);
     croak("Can't bind a reference (%s) for param %d, entry %d",
     neatsvpv(sv,0), i, j);
     if(len > (unsigned int) phs[i]->maxlen)
     phs[i]->maxlen = len;
     /* Do OCI bind calls on last iteration. */
     if( ((unsigned int) j ) == exe_count - 1 ) {
     if(!do_bind_array_exec(sth, imp_sth, phs[i])) {
     Safefree(phs);
     Safefree(phs);
/* Store array of bind typles, for use in OCIBindDynamic() callback. */
imp_sth->bind_tuples = tuples_av;
imp_sth->rowwise = (columns_av == NULL);
oci_mode = OCI_BATCH_ERRORS;
if(autocommit)
oci_mode |= OCI_COMMIT_ON_SUCCESS;
     OCIStmtExecute_log(imp_sth->svchp, imp_sth->stmhp, imp_sth->errhp,
exe_count, 0, 0, 0, oci_mode, exe_status);
     imp_sth->bind_tuples = NULL;
if (exe_status != OCI_SUCCESS) {
          oci_error(sth, imp_sth->errhp, exe_status, ora_sql_error(imp_sth,"OCIStmtExecute"));
if(exe_status != OCI_SUCCESS_WITH_INFO)
return -2;
OCIAttrGet_log(imp_sth, &num_errs, 0, OCI_ATTR_NUM_DML_ERRORS, status);
if(num_errs && tuples_status_av) {
OCIError row_errhp, tmp_errhp;
ub4 row_off;
SV *err_svs[2];
/*AV err_av;/
sb4 err_code;
err_svs[0] = newSViv((IV)0);
err_svs[1] = newSVpvn("", 0);
OCIHandleAlloc_log(imp_sth->envhp, &row_errhp, OCI_HTYPE_ERROR, status);
OCIHandleAlloc_log(imp_sth->envhp, &tmp_errhp, OCI_HTYPE_ERROR, status);
for(i = 0; (unsigned int) i < num_errs; i++) {
OCIParamGet_log(imp_sth->errhp, OCI_HTYPE_ERROR,
tmp_errhp, (dvoid *)&row_errhp,
(ub4)i, status);
OCIAttrGet_log(row_errhp, OCI_HTYPE_ERROR, &row_off, 0,
OCI_ATTR_DML_ROW_OFFSET, imp_sth->errhp, status);
sv_setpv(err_svs[1], "");
err_code = oci_error_get(row_errhp, exe_status, NULL, err_svs[1], debug);
sv_setiv(err_svs[0], (IV)err_code);
av_store(tuples_status_av, row_off,
newRV_noinc((SV *)(av_make(2, err_svs))));
OCIHandleFree_log(tmp_errhp, OCI_HTYPE_ERROR, status);
OCIHandleFree_log(row_errhp, OCI_HTYPE_ERROR, status);
/* Do a commit here if autocommit is set, since Oracle
doesn't do that for us when some rows are in error. */
if(autocommit) {
OCITransCommit_log(imp_sth->svchp, imp_sth->errhp,
OCI_DEFAULT, status);
if (status != OCI_SUCCESS) {
oci_error(sth, imp_sth->errhp, status, "OCITransCommit");
return -2;
if(num_errs) {
return -2;
} else {
ub4 row_count = 0;
          OCIAttrGet_stmhp_log(imp_sth, &row_count, 0, OCI_ATTR_ROW_COUNT, status);
return row_count;

Bug in Oracle's handling of transaction isolation levels?

Hello,
I think there is a bug in Oracle 9i database related to serializable transaction isolation level.
Here is the information about the server:
Operating System:     Microsoft Windows 2000 Server Version 5.0.2195 Service Pack 2 Build 2195
System type:          Single CPU x86 Family 6 Model 8 Stepping 10 GenuineIntel ~866 MHz
BIOS-Version:          Award Medallion BIOS v6.0
Locale:               German
Here is my information about the client computer:
Operaing system:     Microsoft Windows XP
System type:          IBM ThinkPad
Language for DB access: Java
Database information:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
The database has been set up using the default settings and nothing has been changed.
To reproduce the bug, follow these steps:
1. Create a user in 9i database called 'kaon' with password 'kaon'
2. Using SQL Worksheet create the following table:
CREATE TABLE OIModel (
modelID int NOT NULL,
logicalURI varchar (255) NOT NULL,
CONSTRAINT pk_OIModel PRIMARY KEY (modelID),
CONSTRAINT logicalURI_OIModel UNIQUE (logicalURI)
3. Run the following program:
package test;
import java.sql.*;
public class Test {
public static void main(String[] args) throws Exception {
java.util.Locale.setDefault(java.util.Locale.US);
Class.forName("oracle.jdbc.OracleDriver");
Connection connection=DriverManager.getConnection("jdbc:oracle:thin:@schlange:1521:ORCL","kaon","kaon");
DatabaseMetaData dmd=connection.getMetaData();
System.out.println("Product version:");
System.out.println(dmd.getDatabaseProductVersion());
System.out.println();
connection.setAutoCommit(false);
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
int batches=0;
int counter=2000;
for (int outer=0;outer<50;outer++) {
for (int i=0;i<200;i++) {
executeUpdate(connection,"INSERT INTO OIModel (modelID,logicalURI) VALUES ("+counter+",'start"+counter+"')");
executeUpdate(connection,"UPDATE OIModel SET logicalURI='next"+counter+"' WHERE modelID="+counter);
counter++;
connection.commit();
System.out.println("Batch "+batches+" done");
batches++;
protected static void executeUpdate(Connection conn,String sql) throws Exception {
Statement s=conn.createStatement();
try {
int result=s.executeUpdate(sql);
if (result!=1)
throw new Exception("Should update one row, but updated "+result+" rows, query is "+sql);
finally {
s.close();
The program prints the following output:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.lang.Exception: Should update one row, but updated 0 rows, query is UPDATE OIModel SET logicalURI='next2571' WHERE modelID=2571
     at test.Test.executeUpdate(Test.java:35)
     at test.Test.main(Test.java:22)
That is, after several iterations, the executeUpdate() method returns 0, rather than 1. This is clearly an error.
4. Leave the database as is. Replace the line
int counter=2000;
with line
int counter=4000;
and restart the program. The following output is generated:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
     at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
     at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
     at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
     at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
     at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)
     at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)
     at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
     at test.Test.executeUpdate(Test.java:33)
     at test.Test.main(Test.java:22)
This is clearly an error - only one transaction is being active at the time, so there is no need for serialization of transactions.
5. You can restart the program as many times you wish (by chaging the initial counter value first). The same error (can't serialize access for this transaction) will be generated.
6. The error doesn't occur if the transaction isolation level isn't changed.
7. The error doesn't occur if the UPDATE statement is commented out.
Sincerely yours
     Boris Motik

I have a similar problem
I'm using Oracle and serializable isolation level.
Transaction inserts 4000 objects and then updates about 1000 of these objects.
Transactions sees inserted objects but cant update them (row not found or can't serialize access for this transaction are thrown).
On 3 tries for this transaction 1 succeds and 2 fails with one of above errors.
No other transactions run concurently.
In read commited isolation error doesn't arise.
I'm using plain JDBC.
Similar or even much bigger serializable transaction works perfectly on the same database as plsql procedure.
I've tried oci and thin (Oracle) drivers and oranxo demo (i-net) driver.
And this problems arises on all of this drivers.
This problem confused me so much :(.
Maby one of Oracle users, developers nows cause of this strange behaviour.
Thanx for all answers.

Is it a bug in OCI ?

Similar Messages

Maybe you are looking for