Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Mr. Muskrat (4572)

Mr. Muskrat
  reversethis-{moc ... ta} {tarksum.rm}

I'm married with 2 girls. I work as a full time Perl programmer for a Land Mobile Radio company in the Dallas/Fort Worth area.

I am enrolled at the Art Institute of Pittsburgh - Online working towards a Bachelor of Science in photography.

My other blog [blogspot.com]

Journal of Mr. Muskrat (4572)

Friday June 05, 2009
10:36 AM

DBD::Oracle's Persistent OCI Environment

[ #39080 ]

Background:
We have been writing all of our security related information to /var/log/secure. We typically use two database handles in our applications: one for the operator logged in and one for administrative purposes. The operator has just enough privileges to do what he or she needs to do in the application. We recently upgraded to Red Hat Enterprise Linux 5.3 64-bit, Oracle 11 Standard 64-bit, DBI 1.607 and DBD::Oracle 1.22 and everything was happy.

About a week ago we started putting that info into the database as well and everything was running wonderfully. That is until someone mistyped his or her password -- then we started seeing odd behaviors. It started out looking like a return was failing to return and instead crashing the app. One person was working through our code looking for something that had changed and added a cluck before the return in an attempt to shed some light on the situation. The app mysteriously made it further along but started crashing with a OCIHandleAlloc failure.

I found some information on the web that indicated that we might be falling back on 32-bit libraries. Our LD_LIBRARY_PATH environment variable turned out to indeed be pointing to 32-bit libraries so I fixed it. The problem persisted.

I saw that were newer versions of DBI (1.608) and DBD::Oracle (1.23). The DBI install went off without a problem. DBD::Oracle 1.23 was failing LOB tests (a known issue without a resolution) so I kept it at 1.22. The problem persisted.

Next I enabled trace level 1. I logged in using a valid username but an invalid password. That is when I saw that, while we were using two database handles, DBI/DBD::Oracle was refusing to accept the good admin connection as good after the bad connection attempt was made.

Then another coworker pointed out that by default, DBD::Oracle reuses the OCI environment for subsequent connections. Usually this is a good thing but it was causing us problems. Fortunately, the solution was as simple as adding ora_envph => 0 to our connection options. I also removed that cluck and it remained fixed.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.