Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the DBD-Oracle CPAN distribution.

Report information
The Basics
Id: 46739
Status: resolved
Priority: 0/
Queue: DBD-Oracle

People
Owner: Nobody in particular
Requestors: trheath [...] qwest.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in:
  • 1.51_00
  • 1.52



Subject: OCIHandleAlloc(OCI_HTYPE_ERROR) on re-use of cached OCI environment handle
Date: Mon, 08 Jun 2009 11:02:27 -0500
To: bug-DBD-Oracle [...] rt.cpan.org
From: Tim Heath <trheath [...] qwest.net>
Download (untitled) / with headers
text/plain 1.4k
Environment: Redhat RHEL5, kernel build 2.6.18-128.1.10.el5, x86_64 Perl v5.8.8 x86_64-linux-thread-multi (stock RHEL5) Apache 2.2.3 (stock RHEL5 using preforked workers, no multithreading) mod_perl version 2 (stock RHEL5) DBI v1.607 Oracle DBD v1.22 Using apache with mod_perl, if a connect attempt is directed to a shutdown database, the connection fails (as it should) with the following: ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: OCISessionBegin) However, after the database is brought up again, subsequent attempts to connect with the same httpd worker fail with the following: OCIHandleAlloc(OCI_HTYPE_ERROR) failed at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBD/Oracle.pm line 232 Other httpd workers that were not used while the database was down work fine. Restarting httpd clears the problem but is not a viable fix for us. It was suggested by Tim Bunce that the problem could possibly be avoided by including "ora_envhp => 0" in the connect(). This indeed fixed the problem. I am including Tim's comments below: "Try passing ora_envhp => 0 in the connect() attributes. If that fixes it then the bug is probably that dbd::oracle should not use a cached environment handle if it's not usable. (and OCIHandleAlloc(OCI_HTYPE_ERROR) is a reasonable way to test that the environment handle is usable)." Thanks, Tim Heath Qwest Communications
Download (untitled) / with headers
text/plain 246b
If you could rerun your test with dbd_verbose=>15 in the connection string and post the results here I would be able to get a good idea of what is going on in your systme. Myself I do not see the same error you are reporting on my windows box.
Download (untitled) / with headers
text/plain 135b
I have a suspision of what it might be but I will need you to help test the solution as it would be hard for me to recreate the error.
Download (untitled) / with headers
text/plain 2.6k
On Mon Jun 08 12:03:11 2009, trheath wrote: Show quoted text
> Environment: > > Redhat RHEL5, kernel build 2.6.18-128.1.10.el5, x86_64 > Perl v5.8.8 x86_64-linux-thread-multi (stock RHEL5) > Apache 2.2.3 (stock RHEL5 using preforked workers, no multithreading) > mod_perl version 2 (stock RHEL5) > DBI v1.607 > Oracle DBD v1.22 > > Using apache with mod_perl, if a connect attempt is directed to a > shutdown database, the connection fails (as it should) with the > following: > > ORA-01034: ORACLE not available > ORA-27101: shared memory realm does not exist > Linux-x86_64 Error: 2: No such file or directory (DBD ERROR: > OCISessionBegin) > > However, after the database is brought up again, subsequent attempts > to > connect with the same httpd worker fail with the following: > > OCIHandleAlloc(OCI_HTYPE_ERROR) failed at > /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread- > multi/DBD/Oracle.pm line 232 > > Other httpd workers that were not used while the database was down > work fine. Restarting httpd clears the problem but is not a viable fix > for us. > > It was suggested by Tim Bunce that the problem could possibly be > avoided by including "ora_envhp => 0" in the connect(). This indeed > fixed the problem. I am including Tim's comments below: > > "Try passing ora_envhp => 0 in the connect() attributes. > > If that fixes it then the bug is probably that dbd::oracle > should not use a cached environment handle if it's not usable. > (and OCIHandleAlloc(OCI_HTYPE_ERROR) is a reasonable way to test that > the environment handle is usable)." > > > Thanks, > Tim Heath > Qwest Communications > >
Appologies for the massive amount of time it has taken to sort this issue out. The following diff against the current subversion trunk should do what you want. As it has been so long since you reported this I'd understand if you cannot try it out. If you cannot, I'll just have to try and find another way of proving it. Index: dbdimp.c =================================================================== --- dbdimp.c (revision 15333) +++ dbdimp.c (working copy) @@ -591,6 +591,17 @@ forced_new_environment = 1; } } + /* RT46739 */ + if (imp_dbh->envhp) { + OCIError *errhp; + OCIHandleAlloc_ok(imp_dbh, imp_dbh->envhp, &errhp, OCI_HTYPE_ERROR, status); + if (status != OCI_SUCCESS) { + imp_dbh->envhp = NULL; + } else { + OCIHandleFree_log_stat(imp_dbh, errhp, OCI_HTYPE_ERROR, status); + } + } + if (!imp_dbh->envhp ) { SV **init_mode_sv; ub4 init_mode = OCI_OBJECT; /* needed for LOBs (8.0.4) */ Martin -- Martin J. Evans Wetherby, UK


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.