--- In firebird-support@yahoogroups.com, "Ann W. Harrison"
<aharrison@i...> wrote:

> Ivan Prenosil wrote>
> >
> >>Yes, but only if the page is in contention, which in turn

depends on

> >>whether you're using SuperServer or Classic.
> >
> > ???
>
> Ah. Locking a record creates a new record version which will

cause the

> page with the record to be written on commit, regardless of
> architecture. In the general case, that doesn't matter much

because the

> record will have changed - that being the purpose of locking it -

and

> the change has to be written on commit.
> [...]
> Is that clearer?

in my situation, i use locks to make 'group locking' (i.e., i lock
some master row which is not modified, to protect a set of rows that
refer to it; one or several rows are modified but locking them
individually would not work). I commit the transaction if everything
was OK and it leads to many writes slowing done my stuff.

would it be legal in term of FB inner-structure to have some flag
telling these are fake updates and that committing them is just
rollbacking (unless they were really modified by another UPDATE
call)? and so would it be possible to avoid writes at all in
embedded/super server architecture?
I understand that it may involve additional developments but would
it be possible to implement it that way in FB?

maybe should I find another way to do my locking also, any idea?

Armel