Re: [cx-oracle-users] Oracle9i-RAC anomaly

[Anthony T. <ant...@gm...>]

If you are using threads to access Oracle, be aware that Oracle
doesn't really appreciate the use of the same connection in multiple
threads. :-) If you want to do that, you will need to perform locking
as necessary.

If, however, you only want to use one connection per thread than you
simply need to create your connections (or session pools) with the
"threaded =3D True" parameter. I suspect your strangeness will go away
with this option specified. :-)

On 6/23/05, Markus Edelmann <mar...@me...> wrote:
> Hi,
>=20
> 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.
>=20
> Test- and production-environment:
>=20
> - Oracle-RAC-instance-nodes:
>   - SuSE SLES8 with all recommeded patches by Oracle
>   - Oracle9i V. 9.2.0.6.0
>=20
> - 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
>=20
> Even with a simple stress-script executing 3 SQL-statements with *2*
> connections we can generate the same strange result:
>=20
> -- snippet start --
>=20
>     for i in range(connectionSwitches):
>         oraConn1 =3D cx_Oracle.connect(connection1)
>         if connection2:
>             oraConn2 =3D cx_Oracle.connect(connection2)
>         else:
>             oraConn2 =3D oraConn1
>=20
>         for j in range(iterations):
>             c +=3D 1
>             error, text =3D doRettungspunktTable(oraConn1, 3, massnahmenN=
umber,
> DATA_DICT,'GPL') # Statement 1 =3D> delete 1 record and commit
>             error, text =3D doRettungspunktTable(oraConn1, 1, massnahmenN=
umber,
> DATA_DICT,'GPL') # Statement 2 =3D> insert 1 record and commit
>             doSelect(c, oraConn2, massnahmenNumber) # Statement 3 =3D> fe=
tch all
> records
>=20
>         try:
>             oraConn1.close()
>             oraConn2.close()
>         except cx_Oracle.InterfaceError:
>             pass
>=20
> -- snippet stop --
>=20
> What do you expect? Sure, statement 3 is fetching at least 1 record! So f=
ar,
> 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* node=
s
> sometimes the result set of statement 3 is empty!
>=20
> The anomaly is reproducible from different clients.
>=20
> Has anyone observered the same strange behaviour with
> Oracle-RAC-installations?
>=20
> I would be grateful for any advices and hints...
>=20
> Salute,
>=20
> Ede
>=20
> --
> Markus Edelmann
> Email: mar...@me...
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>