Subject | Re: [firebird-support] Re: Firebird Logging |
---|---|
Author | Dmitry Kuzmenko |
Post date | 2013-03-29T07:23:40Z |
Hello, sean!
Thursday, March 28, 2013, 6:11:17 PM, you wrote:
syc> We are not the original developer of the application,
oops.
syc> but have
syc> now been given the task of maintaining/debugging this 750,000 + lines of Delphi 7 code.
OMG.
syc> Does FireBird support isolation levels ?
yes, but if you are not familiar with Firebird, all this idea to
maintain/debug that application seems impossible.
syc> There are a number of
syc> transactions that are waiting for locks to be release, which can be solved by changing the
syc> isolation level to dirty/uncommitted reads. These are for read only transactions.
really? multiversion architecture of Firebird allow to have lock
conflicts only when 2 transactions update same record. There are no
locks when you read data, at all.
Of course, you may set special "isolation level", that will show locks
on reading data, that is being modified, but this is not default, and
you need to set these transaction parameters deliberately.
And, with the new information about application, I can say that
Firebird 2.5 trace/audit will not help you. Because trace helps only
when you know, what happens inside application, i.e. how it works.
If not, you cant compare what happens in Firebird, and what happens in
application.
You just need to check the exception handling in application, and at
the first time find every place where exceptions are being kept back by
the code.
--
Dmitry Kuzmenko, www.ib-aid.com
Thursday, March 28, 2013, 6:11:17 PM, you wrote:
syc> We are not the original developer of the application,
oops.
syc> but have
syc> now been given the task of maintaining/debugging this 750,000 + lines of Delphi 7 code.
OMG.
syc> Does FireBird support isolation levels ?
yes, but if you are not familiar with Firebird, all this idea to
maintain/debug that application seems impossible.
syc> There are a number of
syc> transactions that are waiting for locks to be release, which can be solved by changing the
syc> isolation level to dirty/uncommitted reads. These are for read only transactions.
really? multiversion architecture of Firebird allow to have lock
conflicts only when 2 transactions update same record. There are no
locks when you read data, at all.
Of course, you may set special "isolation level", that will show locks
on reading data, that is being modified, but this is not default, and
you need to set these transaction parameters deliberately.
And, with the new information about application, I can say that
Firebird 2.5 trace/audit will not help you. Because trace helps only
when you know, what happens inside application, i.e. how it works.
If not, you cant compare what happens in Firebird, and what happens in
application.
You just need to check the exception handling in application, and at
the first time find every place where exceptions are being kept back by
the code.
--
Dmitry Kuzmenko, www.ib-aid.com