| Subject | Re: [firebird-support] Long read-only Transactions |
|---|---|
| Author | Helen Borrie |
| Post date | 2008-06-13T01:03:27Z |
At 09:23 AM 13/06/2008, Sergio H. Gonzalez wrote:
If the transaction editor is building a TPB for you, then look for the options to have the read mode 'read' and the transaction isolation 'Read Committed'. But remember what I commented earlier re trying to perform database writes from a read[-only] transaction.
If you don't understand how transactions work, then you are "swimming out of your depth" trying this approach as a solution to the long-running transaction problem. This approach is popular with Russian users, especially those using FIBPlus components and clientdatasets. Not everyone likes this solution (and I am one who dislikes it!) because it forces you to separate reads and writes into different transactions, which breaks the "C" (consistency) part of the "ACID" rules and really pushes Firebird downhill in the league table! It takes a lot of cleverness to achieve consistency with this style of application.
In my opinion, the better way to tackle the question of healthy transaction management with Delphi, if you want to use the Insert/Update/Delete methods, is to stick with read-write transactions and to ENSURE (1) that you avoid components that force you to use soft commits (CommitRetaining); (2) write explicit calls to StartTransaction and Commit - always - and (3) build in a mechanism that forces a regular COMMIT on all transactions.
The two favoured component sets for Firebird are IB Objects and FIBPlus, both of which give you the needed control over transactions (in different ways - the 2 component sets are not similar). The firebird-support list is NOT a Delphi forum. However, both of those products have support lists that you should be able to find on Google.
You might get some of the Delphi-related answers you need by subscribing to the Spanish-language support list - you can subscribe here:
http://firebirdsql.org/index.php?op=lists#sup-fb-spanish
^ heLen
>----- Original Message -----This won't work either, unless you redesign your application so that you never have to perform inserts, updates or deletes in the same transaction as those queries.
>From: "Helen Borrie" <helebor@...>
>Newsgroups: egroups.ib-support
>To: <firebird-support@yahoogroups.com>
>Sent: Thursday, June 12, 2008 9:02 PM
>Subject: Re: [firebird-support] Long read-only Transactions
>
>> Don't confuse a "read-only dataset" with a read-only transaction.
>> A "read-only dataset" is a client-side attribute - the server does
>> not know about it.
>> If the TRANSACTION is a read-write transaction
>> (the default in IBX) then keeping any of its datasets
>> open for long periods will cause the OIT to get stuck
>> and inhibit garbage collection.
>
>> A read-only READ COMMITTED transaction can stay
>> open for longer periods without inhibiting GC.
>> The same is not true if the read-only transaction is
>> SNAPSHOT (what IBX calls Concurrency).
>
>Thanks Helen! Sorry, but I'm not very used with the IBTransaction
>component... I used to have only one for all the app, with this settings:
>
>read_committed
>rec_version
>nowait
>
>So, should I create a new (read-only) one in order to open all my TIBQuerys
>with it?
>How do I create a read-only Transaction component?The transaction must be started with its mode as READ ONLY. From looking through the small amount of documentation that is available for TIBTransaction, it appears IBX does not make this attribute available as a property. TIBTransaction has a Params property where you can pass TPB (transaction parameter block) settings when starting a transaction. I can't see any examples of use, though. You would need to ask on the appropriate Codegear newsgroup, I think.
>The transaction editor has an option which reads "Read-Only Table Stability"No, NEVER! The CONSISTENCY isolation level makes the tables accessed by that transaction unavailable to *all transactions* except the one that has that transaction open. In reality, it is very difficult to acquire a dataset from a transaction with these settings.
>with the parameters:
>
>read
>consistency
>
>Should I use that settings?
If the transaction editor is building a TPB for you, then look for the options to have the read mode 'read' and the transaction isolation 'Read Committed'. But remember what I commented earlier re trying to perform database writes from a read[-only] transaction.
If you don't understand how transactions work, then you are "swimming out of your depth" trying this approach as a solution to the long-running transaction problem. This approach is popular with Russian users, especially those using FIBPlus components and clientdatasets. Not everyone likes this solution (and I am one who dislikes it!) because it forces you to separate reads and writes into different transactions, which breaks the "C" (consistency) part of the "ACID" rules and really pushes Firebird downhill in the league table! It takes a lot of cleverness to achieve consistency with this style of application.
In my opinion, the better way to tackle the question of healthy transaction management with Delphi, if you want to use the Insert/Update/Delete methods, is to stick with read-write transactions and to ENSURE (1) that you avoid components that force you to use soft commits (CommitRetaining); (2) write explicit calls to StartTransaction and Commit - always - and (3) build in a mechanism that forces a regular COMMIT on all transactions.
The two favoured component sets for Firebird are IB Objects and FIBPlus, both of which give you the needed control over transactions (in different ways - the 2 component sets are not similar). The firebird-support list is NOT a Delphi forum. However, both of those products have support lists that you should be able to find on Google.
You might get some of the Delphi-related answers you need by subscribing to the Spanish-language support list - you can subscribe here:
http://firebirdsql.org/index.php?op=lists#sup-fb-spanish
^ heLen