[DUG] Firebird transactions

Thu Jul 22 15:13:50 NZST 2010

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-bounces at delphi.org.nz [mailto:delphi-bounces at 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.Hart at flowsoftware.co.nz>  

Sent: Thursday, July 22, 2010 1:56 PM

To: NZ Borland <mailto:delphi at 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-bounces at delphi.org.nz [mailto:delphi-bounces at 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 at delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe

  _____  

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe

  _____  

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
unsubscribe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20100722/6ed47071/attachment-0001.html 