|
|
Posted by Joshua Ruppert on 07/26/06 20:16
Chung Leong wrote:
> Joshua Ruppert wrote:
> > We're using ODBC instead of the direct MSSQL drivers for one, and we
> > are using the standard odbc_connect() function. Are there any known
> > problems using ODBC with MS SQL Server?
>
> I'm not too familiar with ODBC. The SQL Server ODBC driver does
> connection pooling. With standard CGI you'd get a new connection
> everytime, whereas the connection would be reused in FastCGI. As your
> application works in CGI but no in FastCGI, that's a good place to
> look.
>
> It could also be that you were experiencing deadlocks before, only that
> IIS was terminating the process.
>
> I'm sort of out of ideas. You might want to reproduce the condition (on
> a test environment of course), then run sp_who/sp_who2 in Query
> Analyser to see what is actually happening. It'd also be interesting to
> see if the PHP processes would unfreeze if you stop SQLServer.
No problem. I'm about at the end of my rope too. I've not been able to
reproduce the problem, but it (stranded PHP processes) actually happens
with or without FastCGI, but without FastCGI I'm able to kill the
stranded processes. So I'm able to keep the site running, my big
problem with FastCGI is that when the !@#$ hit the fan I had to reboot.
We are no strangers to SQL Server and resolving dead locks and
optimizing queries but these stranded processes have been a complete
mystery. The problem is that even if we can prove it's caused by a dead
lock, you can't avoid the occasional dead lock. The best you can do is
write the program so it recovers gracefully. We're thinking about
trying PHP 5 to see if that resolves the problem. We may even write a
low level app to clear out stranded processes. It seem like more of a
bug in PHP forever waiting instead of timing out.
Navigation:
[Reply to this message]
|