Subject | Re: [firebird-support] FB crashed again |
---|---|
Author | Helen Borrie |
Post date | 2004-10-28T00:58:27Z |
At 07:09 PM 27/10/2004 -0400, you wrote:
same record(s) without committing. Repeated updates to the same
uncommitted record is a no-no. So, it's something your application or a
stored procedure is doing that you need to fix. I'd be looking first for
some unintended loop in your client code.
it is logged, you know that it has been caught at least once.
However, if your application code is swallowing exceptions and it's allowed
to carry on ad infinitum, perhaps with multiple users/threads all running
code that has the same effect, there will come a point where the in-memory
transaction accounting structure gets so huge that it consumes all of the
available memory. When the server has no memory to work with, there's
nothing it can do.
With luck, the OS will catch a request for unavailable resources and stop
the service (as happened here). Sometimes it will bomb the machine
entirely, because the server doesn't even have enough memory to compose and
pass a resource request. Some Windows versions seem to be able to manage
this kind of thing better than others.
disable the offending service. It's probably not recoverable without a reboot.
./heLen
>VSOFT (Client) Wed Oct 27 18:05:44 2004No, the error itself is thrown when too many updates are being done to the
> Control services error 1061
>
>VSOFT (Server) Wed Oct 27 18:05:44 2004
> Database: D:\IISDOMAINS\ATOZEDSOFTWARE.COM\IWS WEB
>SERVICE\DATABASE\IWSTUDIO.FDB
> internal gds software consistency check (Too many savepoints (287))
>
>Is this from a transaction that's too big?
same record(s) without committing. Repeated updates to the same
uncommitted record is a no-no. So, it's something your application or a
stored procedure is doing that you need to fix. I'd be looking first for
some unintended loop in your client code.
>Even if so shouldn't FB just err and not crash?That error, if caught and handled, won't cause the server to crash. Because
it is logged, you know that it has been caught at least once.
However, if your application code is swallowing exceptions and it's allowed
to carry on ad infinitum, perhaps with multiple users/threads all running
code that has the same effect, there will come a point where the in-memory
transaction accounting structure gets so huge that it consumes all of the
available memory. When the server has no memory to work with, there's
nothing it can do.
With luck, the OS will catch a request for unavailable resources and stop
the service (as happened here). Sometimes it will bomb the machine
entirely, because the server doesn't even have enough memory to compose and
pass a resource request. Some Windows versions seem to be able to manage
this kind of thing better than others.
>Also FB guardian does not restart it..For the latter, Windows has probably written something to the Registry to
disable the offending service. It's probably not recoverable without a reboot.
./heLen