RE: Re[2]: [Firebird-devel] FB2 select for update

[Leyne, S. <sl...@at...>]

Nickolay,

> Every posting works like this (on all databases):
> 1. Read the state of involved accounts to memory and lock them
> 2. Do all changes to the state of accounts and check the result for
> consistency. If there are problems just return w/o rolling back
> transaction - no changes are done in this point.
> 3. Post the state of accounts and transactions itself to the database

I would strongly suggest that you consider where the problem really
lies, within your application design or the database.

It would seem that you really need a lock function in your application
server, and not a database lock.

We have created such a function in our application server, we use it to
address all consistency/contention issues which our application might
encounter -- from locking simple records for editing, to controling
access to functions/structures.

The benefit of implementing the lock function within the application
server is that we do not need to worry about re-engineering our
application should we have to use another database engine (dragged
kicking and screamming).


Sean