I am enrolled at the Art Institute of Pittsburgh - Online working towards a Bachelor of Science in photography.
My other blog [blogspot.com]
Background:
We have been writing all of our security related information to
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.
DBD::Oracle's Persistent OCI Environment 0 Comments More | Login | Reply /