in reply to DBI seems to randomly die

My gut says that this sounds like a race condition, but you seem to be taking reasonable precautions, such as checking the table exists before dropping it and so forth. I spotted one problem in a quick look over the linked code, which may or may not be connected to this:

Using ${Database}.(conv|pt|a)_${RemoteAddr} for your temp table names will generate collisions if you have multiple users accessing the app through the same proxy or NATting firewall, since their requests will be coming from the same address. You can avoid this by generating a random cookie and appending it to the address in your table names. (If you already have a session ID independent of the remote address, it would be perfect for this.)

Back to your original question, how does this fail when it fails? Does it return an error, hang, or what?

Replies are listed 'Best First'.
Re^2: DBI seems to randomly die
by FitTrend (Pilgrim) on Jun 06, 2006 at 19:57 UTC

    I've tested this in an environment where I am the only user and I am still seeing this. If it fails, it dies at the point I issue a drop table on the merge tables (where I commented it in my code snippet). No errors, hanging, or anything. I just get a blank screen. very frustrating. My gut feeling is also possibility of open tables on windows. But I can't seem to identify it consistantly. Even monitoring "show open tables"

    I appreciate your feedback

      You're not seeing anything at all in your browser, not even the output of the
      print qq {<hr>\n} if ($mysqlDebug); print qq {$DatabaseName, $dbS, $dbU, $dbP, $mergeCount, $RemoteAdd +r, $routers<br>\n} if ($mysqlDebug);
      lines at the top of the sub?

      If you're not even seeing that (and you have $mysqlDebug set, of course), then have you tried using telnet to port 80 and/or a packet sniffer to see the complete document returned by apache (including headers and anything else that your browser may eat without displaying it)?

        Yes. If I enable that variable then I see everything until the drop statement. I print the drop statement debug prior to the execusion to make sure they are being issued and it consistently stops on the first. Even if I re-arrange the order :(

Re^2: DBI seems to randomly die
by FitTrend (Pilgrim) on Jun 09, 2006 at 18:34 UTC

    I've changed the merge table names to include an EPOCH Time and random number to make sure same NAT'd requests do not use the exact same table. Still no change..

    I moved the drop tables request to the end of the script so users now: Create Merge, Query Merge, Drop Merge each time. Still no change... However, it now dies on the creation of the merge tables.

    I'm leaning away from a perl coding issue and more toward a file in use issue. I just need to find out how to tell if a file is locked in MySQL.

    Thanks for your help guys