[vwnc] VW7.6 Oracle db interface on HP-UX

Hi,

Some time ago we ran into problems starting a VW7.6 image connecting an Oracle 10 database in multi-threaded mode on a HP platform under HP-UX 11. Investigating the created core dump, gdb showed an error in the OCIInitialize call. Running the image in single (not multi-threaded) mode gave no problem at all. We finally solved the problem by removing the "_threaded" pragma in OracleThreadedInterface >> OCIInitialize: mode with: ctxp with: malocfp with: ralocfp with: mfreefp.

However I feel a bit uncomfortable having changed a method in parcel OracleThapiEXDI shipped with vw7.6. Should this be regarded as an error? Did someone else encounter similar problems?

Thanks.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMHO, your fix is correct and the base parcel is wrong. Same goes for call OCIEnvInit().

The rationale is this: a shared library normally provides an initialization function to initialize global state: for this reason, you want the VM to block whilst the shared library is being initialized to avoid the situation where another thread attempts to use the same or another function from the same library. I don't remember the specifics of the OCI interface, but I'd guess that both these functions are defined as non-reentrant and hence access to them must be serialized.

Nick

On 01/07/09 12:52, op den Akker, Henk wrote:

Hi,

Some time ago we ran into problems starting a VW7.6 image connecting an Oracle 10 database in multi-threaded mode on a HP platform under HP-UX 11. Investigating the created core dump, gdb showed an error in the OCIInitialize call. Running the image in single (not multi-threaded) mode gave no problem at all. We finally solved the problem by removing the "_threaded" pragma in OracleThreadedInterface >> OCIInitialize: mode with: ctxp with: malocfp with: ralocfp with: mfreefp.

However I feel a bit uncomfortable having changed a method in parcel OracleThapiEXDI shipped with vw7.6. Should this be regarded as an error? Did someone else encounter similar problems?

Thanks.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
  

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hello,

you use the call OCIEnvInit to tell the library to use multi-threading.
Thus you cannot call
this function multi-threaded. The same is with the call OCIInitialize
which is called before
to initialize the library. Both calls should be call single-threaded.
Thus your fix is correct.

Clemens

--
Clemens Hoffmann
Senior Consultant

Email: [hidden email]
Tel:   +49 231 975 99 31
Fax:   +49 231 975 99 20

Georg Heeg eK Dortmund
Handelsregister: Amtsgericht Dortmund  A 12812

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks all for this discussion. I've created an AR for this.
AR 57683: Oracle library initialization and env init threaded calls need
further examination.

Among other things, it appears that the threaded call to OCIInitialize()
could conceivably be sent by two separate processes, both trying to
connect at once, say in a busy image at startup. Making that call
non-threaded would probably avoid this problem as well.

I noticed another potential gotcha that we may want to document. The
OCI_THREADED parameter needs to be sent when the library is initialized.
But it is possible to connect to Oracle (and initialize the library with
OCI_DEFAULT) before even loading OracleThapiEXDI. Any new thapi
connections made later would evidently be made against a library that
thinks the calls are all blocking, and which hasn't set up its mutex
helpers. The docs may want to emphasize this more, just in case.

- Dave
______________________________________________________________________
Dave Wallen                      e-mail:  [hidden email]
Development                       phone:  (707)620-0076 or (408)216-4580
Cincom Systems, Inc.                fax:

http://www.cincom.com/visualworks

______________________________________________________________________

multi-threading.
> Thus you cannot call
> this function multi-threaded. The same is with the call OCIInitialize
> which is called before
> to initialize the library. Both calls should be call single-threaded.
> Thus your fix is correct.
>
> Clemens
> >
> > I ran a test using Oracle 9.2 on hpux11 (didn't have 10.2 available
at
> > the time), and found no problems on 7.6 or the current 7.7 build.
> >
> > However, it seems possible that on a faster machine, the results may
> > have been different. Regardless, the change you suggest is harmless
> > and seems reasonable.
> >
> > - Dave
> >
> >
______________________________________________________________________
> > Dave Wallen e-mail: [hidden email]
> > Development phone: (707)620-0076 or (408)216-4580
> > Cincom Systems, Inc. fax:
> >
> > http://www.cincom.com/visualworks
> >
> >
______________________________________________________________________
> >
> >
------------------------------------------------------------------------
> >
> > *From:* [hidden email] [mailto:[hidden email]]
*On
> > Behalf Of *Nick Yannakoyorgos
> > *Sent:* Wednesday, July 01, 2009 6:50 AM
> > *To:* [hidden email]
> > *Subject:* Re: [vwnc] VW7.6 Oracle db interface on HP-UX
> >
> > IMHO, your fix is correct and the base parcel is wrong. Same goes
for
> > call OCIEnvInit().
> >
> > The rationale is this: a shared library normally provides an
> > initialization function to initialize global state: for this reason,
> > you want the VM to block whilst the shared library is being
> > initialized to avoid the situation where another thread attempts to
> > use the same or another function from the same library. I don't
> > remember the specifics of the OCI interface, but I'd guess that both
> > these functions are defined as non-reentrant and hence access to
them in
> > the OCIInitialize call. Running the image in single (not
> > multi-threaded) mode gave no problem at all. We finally solved the
> > problem by removing the "_threaded" pragma in
OracleThreadedInterface ------------------------------------------------------------------------ ------------------------------------------------------------------------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc