Subject | RE: [firebird-support] Transaction Optoins |
---|---|
Author | Chad Z. Hower |
Post date | 2005-06-05T09:05:17Z |
:: "Concurrency" is an isolation level, another word for "Snapshot" or
:: "Repeatable Read". Other members of this paradigm are "Read
:: Committed"
:: ("ReadCommitted" in .NET?) and "Snapshot Table Stability"
:: ("Consistency" in
:: .NET?)
ReadRepeatable. The issue is this - if I use FB.NET directly, I can specify
FB as I want it. But now Im porting a library to be "indepenedent" so I cant
use the FB specifics. I have to use the .NET values....
I was using this:
_TxOpts =
FbTransactionOptions.Concurrency | FbTransactionOptions.Read
| (aNeedsToWrite ? FbTransactionOptions.Write : 0);
Based on a long thread and advice here many months ago. Currently I am not
using the aNeedsToWrite, but I had planned for it. So currently all are
Concurrency + Read + Write.
In .NET I have the following choices:
switch (this.isolationLevel)
{
case IsolationLevel.Serializable:
options |=
FbTransactionOptions.Consistency;
break;
case IsolationLevel.RepeatableRead:
options |=
FbTransactionOptions.Concurrency;
break;
case IsolationLevel.ReadUncommitted:
options |=
FbTransactionOptions.ReadCommitted;
options |=
FbTransactionOptions.RecVersion;
break;
case IsolationLevel.ReadCommitted:
default:
options |=
FbTransactionOptions.ReadCommitted;
options |=
FbTransactionOptions.NoRecVersion;
break;
}
What I need is essentially my reads to be versioned - and repeatable, but
not block other write transactions on the same record. It's a financial
system - the performance penalty is ok so long as my transactnois are
isolated. If there are write conflicts - I get a version/update error and in
fact we trap this in a few spots.
What is consistency? :)
Should I be using just the RepetableRead option? Is that pretty much what I
had before?
:: Besides isolation, a transaction can be Read Only or
:: Read-Write. I don't
:: know the .net interface too intimately, but it looks as if
:: you have some
:: flag to set to indicate whether the transaction needs to be
:: read-write. Other interfaces tend to follow the engine's
:: default, which is
:: read-write, with readonly by request.
options |=
FbTransactionOptions.Concurrency;
Will this not make it read+write? Aah.. Just above this case statement is:
FbTransactionOptions options =
FbTransactionOptions.Write;
options |= FbTransactionOptions.Wait;
So Write I assuem also implies a read? :)
:: There are other parameters for a transaction, too.
:: Wait/NoWait; and, for
:: a ReadCommitted transaction, RecordVersion/NoRecordVersion.
:: There's also
:: an optional Reserving clause that lets you take table locks,
:: with various
:: sub-parameters to set up how the locks are to be respected by other
:: transactions. Carlos should be able to answer any questions
:: about the .NET
:: provider's defaults and any peculiarities of implementation...
Lots of options there... Maybe someday I'll figure all them out and wirte a
more detailed article than exists now. But it appears that I don't need the
+Read as if +Write is there than Read is implcit? So I guess my only major
question now would be, what is FbTransactionOptions.Consistency?
:: "Repeatable Read". Other members of this paradigm are "Read
:: Committed"
:: ("ReadCommitted" in .NET?) and "Snapshot Table Stability"
:: ("Consistency" in
:: .NET?)
ReadRepeatable. The issue is this - if I use FB.NET directly, I can specify
FB as I want it. But now Im porting a library to be "indepenedent" so I cant
use the FB specifics. I have to use the .NET values....
I was using this:
_TxOpts =
FbTransactionOptions.Concurrency | FbTransactionOptions.Read
| (aNeedsToWrite ? FbTransactionOptions.Write : 0);
Based on a long thread and advice here many months ago. Currently I am not
using the aNeedsToWrite, but I had planned for it. So currently all are
Concurrency + Read + Write.
In .NET I have the following choices:
switch (this.isolationLevel)
{
case IsolationLevel.Serializable:
options |=
FbTransactionOptions.Consistency;
break;
case IsolationLevel.RepeatableRead:
options |=
FbTransactionOptions.Concurrency;
break;
case IsolationLevel.ReadUncommitted:
options |=
FbTransactionOptions.ReadCommitted;
options |=
FbTransactionOptions.RecVersion;
break;
case IsolationLevel.ReadCommitted:
default:
options |=
FbTransactionOptions.ReadCommitted;
options |=
FbTransactionOptions.NoRecVersion;
break;
}
What I need is essentially my reads to be versioned - and repeatable, but
not block other write transactions on the same record. It's a financial
system - the performance penalty is ok so long as my transactnois are
isolated. If there are write conflicts - I get a version/update error and in
fact we trap this in a few spots.
What is consistency? :)
Should I be using just the RepetableRead option? Is that pretty much what I
had before?
:: Besides isolation, a transaction can be Read Only or
:: Read-Write. I don't
:: know the .net interface too intimately, but it looks as if
:: you have some
:: flag to set to indicate whether the transaction needs to be
:: read-write. Other interfaces tend to follow the engine's
:: default, which is
:: read-write, with readonly by request.
options |=
FbTransactionOptions.Concurrency;
Will this not make it read+write? Aah.. Just above this case statement is:
FbTransactionOptions options =
FbTransactionOptions.Write;
options |= FbTransactionOptions.Wait;
So Write I assuem also implies a read? :)
:: There are other parameters for a transaction, too.
:: Wait/NoWait; and, for
:: a ReadCommitted transaction, RecordVersion/NoRecordVersion.
:: There's also
:: an optional Reserving clause that lets you take table locks,
:: with various
:: sub-parameters to set up how the locks are to be respected by other
:: transactions. Carlos should be able to answer any questions
:: about the .NET
:: provider's defaults and any peculiarities of implementation...
Lots of options there... Maybe someday I'll figure all them out and wirte a
more detailed article than exists now. But it appears that I don't need the
+Read as if +Write is there than Read is implcit? So I guess my only major
question now would be, what is FbTransactionOptions.Consistency?