At the expense of sounding callous, I recommend learning to trust the
transaction manager.

Your proposed mechanism would not be visible outside of the current
transaction, so it could not semaphore other concurrent transactions
about the "lock" status of the row.

In most DBMS, rollback is twice as expensive as commit. Ann could
probably tell you better if this is true in Firebird. At best, it is
equally expensive so there is no savings.

Why do you need "locking" of this sort? There are probably a number of
alternative mechanisms that will accomplish your purpose.

On Sun, 2005-02-13 at 14:16, benedicte_asselin wrote:
>
>
>
> hello,
>
> 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
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>