You, almost certainly, have an application that's starting a transaction,
and not commiting it, thus creating your "transaction gap".


Best regards,
Fred Wilson
SE, Böwe Bell & Howell
fred.wilson@... <mailto:fred.wilson@...>



-----Original Message-----
From: Martin Dew [mailto:martin.dew@...]
Sent: Tuesday, December 02, 2003 6:29 AM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Who's guilty?



Johannes Pretorius schrieb:

>> Sorry What I tried to say was
>>
>> Personal I believe your problem ,due to the LARGE transaction gap, is

>> a procedure that gets called on a trigger that gets affected by a
>> record change that the procedure itself creates.

>But which would still run inself the _SAME_ transaction context and

would NOT create a new transaction for every update it handles since
this is impossible.

>So this can't be the reason for the enormous gap.


>I think it's like Helen said: Something is happening on the client.

>Maybe there's a single connection (or sth. like that, for example a

little program) surverying the database without ever doing any commit.

>Luc.

I really appreciate all the ideas coming from people. The only way I
have ever replicated this within my own test rig is by crashing my app
during a long running transaction, this made the OIT/ OAT and OS stick
and subsequent activities after reloading the app would continue to move
the NT onwards and leave the other transactions stats stuck...
However.... I left it all alone for 15 minutes and came back to the
stats and they had corrected themeselves ??? This does not happen ever
at my sites but did happen at my test rig.. I asked a question on
interbase.general newsgroup but never got a conclisive answer (btw my
test rig was using firebird 1.5 rc7). I will include below the
transcript of the conversation.. Hopefully someone else will be able to
come up with some other theories...

Transcript
======

I picked a part of my application that can sometimes run a long query.
During it I crashed the application, and it left the header stats as
below;
[
Oldest transaction 3594
Oldest active 3595
Oldest snapshot 3595
Next transaction 3689
]

I then logged back into my app and the next transaction kept moving up
by
for every event that worked fine before and moved the transactions along
in
sync, they now never move the old ones along.. so.. how can I cope with
this, say for example my users decide they should [end task] on my app
during a query etc how can I make sure that does not leave the IB Server
in
this kind of condition..? I assume that from this point onwards it will
never sweep due to the gap between the OIT and the OAT never moving
upwards.... so does this scenario seriously degrade the performance of
IB
the longer it goes on for ? Can I handle this somehow ? In my
environment it
is not really anoption to have scheduled weekly backup and restores on
3gb
databases as my customers are 24/7 busy and cannot afford to be without
the
system.

Hope someone can offer some advice on this.. I will continue to test my
application in the other areas to see if I can find anywhere that leaves
a
transaction open.

In addition, if you leave the database alone for about 15-20mins it
seems to
catch up on itself ?? Although this does not seem to happen at the site
using 6.0.1.6, I am using FB 1.5 (RC6) as I am evaluating it, I will
also
hopefully be trying IB 7.1 when they release the eval with sp1
incorporated.

Is this a function within FB ? Is IB 6.0.1.6 supposed to have this
function
it i and it does not work ??

This is all a bit strange.. :-(

Any help again appreciated.

-----reply from someone to my question

That makes sense. InterBase will automatically rollback any active
transaction if it detects that the connection to the client has been
lost. The only way that IB can determine if the connection is alive is
to monitor each connection for traffic. If the server does not receive
any packets from the client for a specified period of time the server
sends a packet to the client. If the server does not get a response it
closes the connection and rolls back all active transactions. The time
the server waits before sending a packet to the client is controlled
by the DUMMY_PACKET_INTERVAL directive in the ibconfig file.

Make sure this is set to a reasonable number at the client site where
the problem occurs. If DUMMY_PACKET_INTERVAL is zero the server will
never detect a dead client. If you have to change this value you will
have to stop and restart the IB server to make it reread the ibconfig
settings.

----my reply....

thanks again for continued support. I have read up on the dummy
packet interval, is my understanding that this only applies if you use
a TCP/IP connection string to attach to the database ? Our connection
strings are named pipe as our sites use dial up 64k telephone lines to
connect in remote base computers to operate on our system, if we allow
this dummy packet to be sent say every 3 minutes out over these lines
it will incure a large cost for our customers.

Could you or someome else possibly clarify the use of dummy packet
interval over a named pipe interbase connection as apposed to a TCP/IP
connection.

---- my reply again

I would be interested to find out the correct answers for this query.

I used named pip connection strings for my testing and in the first
instance
it seemed to catch up with itself as I previously mentioned, I restested
and
this time I let 30 minutes pass by without doing anything else interbase
related, it did not catch up with itself, I then logged my application
in
again which would cause some interbase work and transactions and it
immediately caught up with itself.. The reason I feel this is odd is
that it
is displaying 2 causes of action for clearup instead of just always
catching
up on itself automatically.

Any help would be much appreciated

End.. No more answers given in newsgroup..




To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>






Yahoo! Groups Sponsor

ADVERTISEMENT

<http://rd.yahoo.com/SIG=12c2lqqjm/M=258297.4155332.5363524.4049140/D=egroup
web/S=1705115386:HM/EXP=1070458138/A=1683962/R=0/*http://www.techsmith.com/r
dr/ban/syah/default.asp> click here

<http://us.adserver.yahoo.com/l?M=258297.4155332.5363524.4049140/D=egroupmai
l/S=:HM/A=1683962/rand=850378293>

To unsubscribe from this group, send an email to:
firebird-support-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .