I myself still suspect a logic fault in the code running on the Windows 2000 machine.
Sidebar: You refer to this Windows 2000 machine as a "slow machine". But Trust Me (tm). It is *not* a slow machine compared to the first PC kit I worked on when developing Windows clent/server applications handling scores, if not hundreds of transactions per second (certainly more than 5!), back in 1991 when we were running Windows/386 (and later Windows 3.0) on the clients and Novel NetWare on the servers with a Gupta SQLBase NLM, and the client code was running in an interpreted 4GL! (Gupta SQL/Windows). The server was of course a much faster machine than the client. I think the server was a powerful 486 CPU blazing along at 33MHz and stuffed to the gills with as much as 32 MB of RAM, whilst the clients were typically 12 MHz 286's with 33 MHz 386's reserved for our development machines and "super users", with as much as 8 or even 16 MB of RAM. And no, not a single one of those "M"s should be a "G". Dammit but I feel old sometimes... J As to your supplementary question... what do you mean by "Transaction ID" ? If you mean the ID's generated *within* the transaction, then the ID's will be available as soon as they have been generated to the process running within that transaction, even before the transaction has been committed. The ID's (and the records) would not normally be available to other processes until the transaction has committed, depending on the isolation level in which those other transactions are themselves running. For transactions isolated from that which generates the ID and the record, the processing will be sufficiently fast that - as far as I can surmise from the scenario you describe - the commit of the transaction and the availability of the data created within that transaction will to all intents and purposes be instantaneous. From: delphi-boun...@delphi.org.nz [mailto:delphi-boun...@delphi.org.nz] On Behalf Of John Bird Sent: Thursday, 22 July 2010 14:51 To: NZ Borland Developers Group - Delphi List Subject: Re: [DUG] Firebird transactions 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 <mailto:cameron.h...@flowsoftware.co.nz> Sent: Thursday, July 22, 2010 1:56 PM To: NZ Borland <mailto:delphi@delphi.org.nz> 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 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
_______________________________________________ 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
