> 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.

Are you sure it is the locking of master row which is slowing
things down ? (for updating several rows you have to update/lock
one master row, i.e. the lock causes relatively less load
than the updates)

Your problem can also be too many back-versions
(do you have any relatively long-running transactions?).

>
> 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?

You can also lock the master record from another transaction -
after you commit the changes, unlock the row by rolling back the transaction.
(then there is a chance the lock will be only in memory
and will not go to disk)

Ivan
http://www.volny.cz/iprenosil/interbase/