Each transaction fires a inserts one line in one table and populates about 20
fields, and inserts multiple lines in another with similar number of fields.
And multiple of these transactions are coming from the slow Windows 2000 box
each second in this burst.
Within each transaction the program fires the generator once for ID for one
table, and once for each line ID of the other table, and writes one line to a
log file after the transaction commits. The generator is being fired
separately for the occasional duplicate transactions (ie they have different
ID's even though other fields are the same) yet only one line appears in the
log file. Hence the mystery!
So in answer to what you asked, it is several transactions per second, each
involving inserts into two tables.
>From what everyone is implying it looks like Firebird should not be the
>culprit with this volume on a fast server unless an extremely slow
>workstation can slow any of the transactional stuff down..... This is good,
>mainly wanted to eliminate the Firebird server as a area to investigate.
Practical question - if I want to do a query on the transaction ID after it is
finished is it visible the exact instant after the commit transaction is done,
or may there any lag while Firebird does its housekeeping - or while some
cached stuff on the slow workstation is not saved yet?
John
From: Cameron Hart
Sent: Thursday, July 22, 2010 1:56 PM
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Firebird transactions
Is transaction the right term? Or do you really mean records - ie you are
inserting 5 records per second for 20-30 seconds.
Running a series of insert statements (within one transaction) against firebird
I can get up to 2500 per second on a laptop alone.
From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On
Behalf Of John Bird
Sent: Thursday, 22 July 2010 1:27 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Firebird transactions
The error is same transaction going in twice, each one with different ID (from
the Generator) but otherwise the same. The generator is fired by the program,
so looks like its the calling program somehow doing the same processing twice.
Not helped by the fact that the program is running these bursts of
transactions on an old slow Windows 2000 box...just wanted to eliminate
Firebird not keeping up.
John
Hi
FB should easily handle this. What is your error?
Cheers
Rob
On 22/07/2010 12:30 p.m., John Bird wrote:
Dealing with a timing issue involving Firebird, probably the cause is a slow
workstation running the processing program. The workstation occasionally sends
a burst of transactions, each involving adding new records to the same two
tables. I presume Firebird can handle this The server is a FAST quad core
Windows 2003 server running Firebird 2.0 - it should handle a burst of
transactions at up to 5 per second for up to 20 or 30 seconds? John
_______________________________________________NZ Borland Developers Group -
Delphi mailing listPost: del...@delphi.org.nzadmin:
http://delphi.org.nz/mailman/listinfo/delphiUnsubscribe: send an email to
delphi-requ...@delphi.org.nz with Subject: unsubscribe
--------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
--------------------------------------------------------------------------------
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject:
unsubscribe