[cx-oracle-users] Oracle9i-RAC anomaly

[Markus E. <mar...@me...>]

Hi,

we' ve observered some strange Oracle-RAC behaviour with a thread-based 
Webware4Python-application and an anonymous Oracle-connection pool based on 
cx_Oracle-connection against an Oracle-RAC-instance with 3 nodes.

Test- and production-environment:

- Oracle-RAC-instance-nodes:
  - SuSE SLES8 with all recommeded patches by Oracle
  - Oracle9i V. 9.2.0.6.0

- AppServer with OCI-client:
  - SuSE SLES9 with all recommended patches by Oracle
  - Webware4Python V. 0.8.1
  - Python V. 2.3.5 compiled from sources
  - Oracle9i-OCI-client V. 9.2.0.6.0
  - cx_Oracle V. 4.1 compiled and linked against Oracle from sources

Even with a simple stress-script executing 3 SQL-statements with *2* 
connections we can generate the same strange result:

-- snippet start --

    for i in range(connectionSwitches):
        oraConn1 = cx_Oracle.connect(connection1)
        if connection2:
            oraConn2 = cx_Oracle.connect(connection2)
        else:
            oraConn2 = oraConn1

        for j in range(iterations):
            c += 1
            error, text = doRettungspunktTable(oraConn1, 3, massnahmenNumber, 
DATA_DICT,'GPL') # Statement 1 => delete 1 record and commit
            error, text = doRettungspunktTable(oraConn1, 1, massnahmenNumber, 
DATA_DICT,'GPL') # Statement 2 => insert 1 record and commit
            doSelect(c, oraConn2, massnahmenNumber) # Statement 3 => fetch all 
records

        try:
            oraConn1.close()
            oraConn2.close()
        except cx_Oracle.InterfaceError:
            pass
    
-- snippet stop --

What do you expect? Sure, statement 3 is fetching at least 1 record! So far, 
so good, if the script is running against a Oracle9i-RAC with *1* node.
But, if the script is running against a Oracle9i-RAC with *2* or *n* nodes 
sometimes the result set of statement 3 is empty!

The anomaly is reproducible from different clients.

Has anyone observered the same strange behaviour with 
Oracle-RAC-installations?

I would be grateful for any advices and hints...

Salute,

Ede
  
-- 
Markus Edelmann
Email: mar...@me...