Hi Federico,

may be it's not quite appropreate place for your question. The answer is you
can do it easily in Firebird which is by default has natural isolation level
for multi-user. This is the most prominent feature of Firebird/Interbase and
may be because of the 'Monster RDBMS' do not have it and I am just wonder
why. As one of the implementation of this feature (so-called
multi-versioning) is not something completely non-understandable and was in
the heads of not only database developers but some users.

Alexander

----- Original Message -----
From: "Federico Tello Gentile" <federicotg@...>
To: <Firebird-Architect@yahoogroups.com>
Sent: Wednesday, September 01, 2004 8:00 AM
Subject: [Firebird-Architect] Transaction Isolation Levels


> This comment is based on my short experience using FB and by working
> in a project using Oracle.
> I see people in the project where I am currently working spend time
> and a lot of effort coding to achieve something I think should be
> provided by the database engine.
> This is a intranet web application with around 50 simultaneous users,
> very interactive, lots of selects and inserts in the database, the
> company has about 10 branches all using the same application instance.
> There are a few (2 or 3) calculations that take about 5/10 minutes and
> (like sending the bills to the stock managing system) and during that
> calculation it is not desirable to have changes to that data. As the
> current configuration in the oracle database (maybe the only
> possible?) is that once you open a transaction if other transactions
> commit, you see the changes even when you did not commit or rollback
> your transaction people here are marking the rows as "in calculation"
> in one transaction and then in a separate transaction doing the actual
> calculation (that takes a while). This brings a lot of issues like
> unmarking the rows on any error, taking care of any process not to use
> the marked rows, etc.
> In another place a different strategy was used. Oracle has a "select
> for update" statement. This locks all the selected rows so nobody can
> write to them. This is not automatic at all, you have to call that
> statement explicitly.
>
> My question or doubt is, isn't this much simpler in FB? My guess is
> all you need is to set up Repeatable_Read isolation level and you will
> never have data changed while you are inside one transaction. Am I
> right?
> If that is the case, when another transaction updates the data I'm
> reading will those updates be stopped until my transaction finishes?
> In the case the write is prevented, I think it would be the same as
> the select for update with the non-trivial advantage of being
> transparent to the application.
>
> Sorry for the long post, maybe you could title it FB features you miss
> when you are doing real work.
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
> E1-I: This message has been scanned for viruses and dangerous content by
UML's antivirus scanning services.
>
>
>