This one had me seriously stressed out...
Co-worker changed some code. Code suddenly stops working correctly, but for no apparent reason. Error log didn't make any sense - different stopping point each time. Then finally, it dawned on me...
Little safety tip - create database handles after you do your forking & stuff when working with Oracle. :)
I'd slap him for moving that line, but then it's partially my own fault for not putting a comment about it in there.
Re:With any database
pudge on 2002-02-15T18:04:24
In Slash, we connect with DBI before Apache forks, cache some data and do whatever we need to do in the parent process, kill the DBI handle, and then reopen a new DBI handle in each child.
Re:With any database
djberg96 on 2002-02-15T20:25:13
Actually, it *is* RDMS specific, at least that's what the docs indicate. I've only ever used DBI with Oracle. From the DBI docs (note the italicized part):InactiveDestroy (boolean)
This attribute can be used to disable the database engine related effect of DESTROYing a handle (which would normally close a prepared statement or disconnect from the database etc). For a database handle, this attribute does not disable an explicit call to the disconnect method, only the implicit call from DESTROY.
This attribute is specifically designed for use in Unix applications that ``fork'' child processes. Either the parent or the child process, but not both, should set InactiveDestroy on all their shared handles. Note that some databases, including Oracle, don't support passing a database connection across a fork.
Doesn't work with Threads either (tried it in Ruby).
Re:With any database
autarch on 2002-02-15T21:03:56
And it doesn't work with MySQL. I think I've seen this problem with Postgres too.
I haven't tried it with any others.
At the very least, its not Oracle specific and I'd expect to fail more often than not.
