--- In firebird-support@yahoogroups.com, Thomas Steinmaurer <ts@...> wrote:

>
> > Hi. In highly concurrent environment, part of an app is using .NET RepeatableRead transaction to read data from few tables.
> > I noticed that during these reads, writers to these tables experience major slowdown.
> > So question is this:
> > Does (Concurrency,ReadWrite) (.NET RepeatableRead) has major impact writers?
>
> I'm not familiar with the .NET driver ...
>
> * What does "major slowdown" mean?
> * Is repeatable read involved for all transactions or read committed as
> well?
> * If read committed, are you using REC_VERSION or no record versions?
> * Do you use WAIT or NO WAIT at transaction level?
> * Do you end up with long running transactions? What does gstat -h and
> or the monitoring tables say?
> * When committing. Do you use commit retaining or "hard" commits?
>
> More questions than answers ... ;-)
>
>
> --
> With regards,
> Thomas Steinmaurer
> http://www.upscene.com/
>
> Professional Tools and Services for Firebird
> FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
>

First thank you for your time.
It seems that .NET Repeatable read translates to
Concurrency, Write, NoWait
Id does not specify RecVersion, so it defaults to something.
If it defaults to NoRecVersion, then it seems understandable that
this transaction possibly waits for concurrent writers to commit, which would explain slow writes and slow execution of this transaction.

I need readonly snapshot of few related tables, so i figure that
Concurrency, Read, NoWait, RecVersion would be solution.

Any opinoon on this?
And again, thanks for your time...