Subject | Re: firebird frozing ... |
---|---|
Author | Alexander V.Nevsky |
Post date | 2003-08-22T15:19:26Z |
--- In firebird-support@yahoogroups.com, Alessandro GARDICH
<gremlin@g...> wrote:
idiots", no more, but some observations on you code:
1. FB don't support Dirty Read isolation level, it is substituted to
somewhat else by your access library, don't know to which one.
2. Seems you are trying to randomly update records. Nothing unusual
you have many exceptions about lock conflicts (they are named
deadlock even if it is simple conflict). In wait mode which you use
scenario is:
one transaction updated some record
another transaction tried to do the same with this record and waits
what first one will do - if rollback, then it will run further, if
commit, it will raise exception.
since you always commit, exception is always raised.
About freeze - you run 10 fast applications which hammers data and in
some minutes creates a lot of versions (millions, I think) of the
records in your table. Sooner or later garbage collection starts (or
even sweep, if your setting for it is default 20 000 transactions) and
server is extremely busy identifying unneeded already versions and
freeing space occupied by them. If your real application requires such
behaviour, I think you should re-examine it, no one RDBMS can do this,
every one will fail by own mode - FB collecting garbage, MSSQL -
stopping read practically all in sensible modes or impudently lying on
read in Dirty mode.
Best regards, Alexander.
<gremlin@g...> wrote:
> hi to all ...clients stopped,
>
> I have many problems with firebird and ibpp
> firebird server simply stop to work !!!
> the process 'fbserver' is still alive, cpu occupation to 0%, all
> difficult to make new connection ... seem is in a deadlock :( ...Alessandro, I can read C programs in books like "Computers for
idiots", no more, but some observations on you code:
1. FB don't support Dirty Read isolation level, it is substituted to
somewhat else by your access library, don't know to which one.
2. Seems you are trying to randomly update records. Nothing unusual
you have many exceptions about lock conflicts (they are named
deadlock even if it is simple conflict). In wait mode which you use
scenario is:
one transaction updated some record
another transaction tried to do the same with this record and waits
what first one will do - if rollback, then it will run further, if
commit, it will raise exception.
since you always commit, exception is always raised.
About freeze - you run 10 fast applications which hammers data and in
some minutes creates a lot of versions (millions, I think) of the
records in your table. Sooner or later garbage collection starts (or
even sweep, if your setting for it is default 20 000 transactions) and
server is extremely busy identifying unneeded already versions and
freeing space occupied by them. If your real application requires such
behaviour, I think you should re-examine it, no one RDBMS can do this,
every one will fail by own mode - FB collecting garbage, MSSQL -
stopping read practically all in sensible modes or impudently lying on
read in Dirty mode.
Best regards, Alexander.