| Subject | Re: [firebird-support] Does anyone know what these message mean ? |
|---|---|
| Author | Helen Borrie |
| Post date | 2006-12-05T07:01:16Z |
At 05:09 PM 5/12/2006, you wrote:
server ran out of capacity to handle any more - specifically to
rewind if/when the offending client decides to roll back the
work. Suspect a recursive trigger here, or an infinite loop in your
application involving an update, that is causing the same record to
get updated a gazillion times inside the same uncommitted transaction.
symptoms, suspect an unhandled update conflict possibly involving a
trigger on the offending operation that is updating a different table
and causing the conflict.
rebooting the machine).
stopped the service; or could be the same client tried to reconnect
through a broken socket; or a client tried to connect after reboot,
before the necessary services (TCP/IP, Firebird server) had actually
started up.
Solution: look for that misbehaving trigger or that death loop in
your app and fix it; catch and handle update conflicts in your
application code so that users don't have to crash out when they get
one; find out who has the kind of network access that allows them to
stop services, and provide a little user education about why stopping
the database service/rebooting the server isn't your everyday way to
solve problems.
./heLen
>This has just happened. The version is 1.5.3.4870means there were so many hits on the same record version that the
>
>Thanks
>
>ALPINE-FS (Server) Tue Dec 05 16:29:11 2006
> Database: D:\NDATA\AGBIZ.GDB
> deadlock
> update conflicts with concurrent update
> operation was cancelled
> internal gds software consistency check (error during savepoint
> backout (290))
server ran out of capacity to handle any more - specifically to
rewind if/when the offending client decides to roll back the
work. Suspect a recursive trigger here, or an infinite loop in your
application involving an update, that is causing the same record to
get updated a gazillion times inside the same uncommitted transaction.
>ALPINE-FS (Server) Tue Dec 05 16:29:11 2006Normally just a regular update conflict. But, given the other
> Database: D:\NDATA\AGBIZ.GDB
> deadlock
> update conflicts with concurrent update
symptoms, suspect an unhandled update conflict possibly involving a
trigger on the offending operation that is updating a different table
and causing the conflict.
>ALPINE-FS (Server) Tue Dec 05 16:29:11 2006A human being stopped the server (or caused it to be stopped by
> Database: D:\NDATA\AGBIZ.GDB
> deadlock
> update conflicts with concurrent update
>
>ALPINE-FS (Server) Tue Dec 05 16:29:11 2006
> Database: D:\NDATA\AGBIZ.GDB
> deadlock
> update conflicts with concurrent update
>
>ALPINE-FS (Server) Tue Dec 05 16:29:11 2006
> Database: D:\NDATA\AGBIZ.GDB
> deadlock
> update conflicts with concurrent update
>
>ALPINE-FS (Client) Tue Dec 05 16:55:53 2006
> C:\Program Files\Firebird\Firebird_1_5\bin\fbserver.exe: normal shutdown
rebooting the machine).
>ALPINE-FS (Client) Tue Dec 05 16:55:53 2006Remote client tried to connect to the server after *whoever* had
> Control services error 1061
stopped the service; or could be the same client tried to reconnect
through a broken socket; or a client tried to connect after reboot,
before the necessary services (TCP/IP, Firebird server) had actually
started up.
Solution: look for that misbehaving trigger or that death loop in
your app and fix it; catch and handle update conflicts in your
application code so that users don't have to crash out when they get
one; find out who has the kind of network access that allows them to
stop services, and provide a little user education about why stopping
the database service/rebooting the server isn't your everyday way to
solve problems.
./heLen