Cursor lock and sql command

[Ivan Smahin]

On Jul 30, 2014, at 8:45 PM, François Van Lerberghe <frvanlerberghe at gmail.com> wrote:

> Because one user wants to modify this record. And I don't want another been
> able to modify (or delete) the same record at the same time. Isn't it for
> this exact reason that the lock was there ?
> 

No, locking was the part of old-school transactions. I mean it is internal feature to implement ACID properties.
Later, when versioned transactions will be introduced, we are going to remove that "locks" because it is not used anymore.

The logic you describe above seems to be a part of your app business logic. So you should implement it "on the same level".
For example - if you want to "lock"  record you can introduce some additional field, say boolean - "fld_Lock" and set it to "true".
So, another cursors... of "your-app-domen" will be aware of locked records ("DELETE FROM t1 WHERE fld_Lock = false AND ....").

In other words - you should not think of locks as "the-only-mechanism" to guarantee "atomic" or/and "isolation".
BTW, currently - any command (including sql-commands) is atomic.


-- 
Best regards,
Ivan Smahin
Senior Software Engineer
Paradigma Software, Inc
Valentina - The Ultra-Fast Database
http://www.valentina-db.com