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

History Show all quoted text
  Mon Jun 08 12:03:11 2009 trheath [...] qwest.net - Ticket created
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>
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
  Thu Jul 02 17:09:35 2009 champoux [...] pythian.com - Correspondence added
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.
  Thu Jul 02 17:09:36 2009 The RT System itself - Status changed from 'new' to 'open'
  Fri May 07 16:16:52 2010 champoux [...] pythian.com - Correspondence added
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.
  Sun Jun 24 07:55:31 2012 bohica [...] ntlworld.com - Correspondence added
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
  Mon Sep 10 05:15:15 2012 bohica [...] ntlworld.com - Status changed from 'open' to 'patched'
  Tue Oct 23 08:33:41 2012 bohica [...] ntlworld.com - Status changed from 'patched' to 'resolved'
  Tue Oct 23 08:33:41 2012 bohica [...] ntlworld.com - Fixed in 1.51_00 added
  Tue Oct 23 08:33:41 2012 bohica [...] ntlworld.com - Fixed in 1.52 added