NoLocks // 1.9.8b10 adoption of record locks. Feedback

[Ruslan Zasukhin]

on 7/4/03 22:50, Carsten Friehe at rblists at carsten-friehe.de wrote:

> Hi Ruslan!
> 
>>    make transactions AS SHORT AS POSSIBLE in time,
>>    and select as FEW records as possible. In ideal just one.
> 
> I didn't have changed my application to the new calling format because I
> don't have the time now and in the next weeks. But it looks great.
> 
> I know this from Oracle where it is done in another way. If you are calling
> a normal "select xyz from abc where ..." you don't lock the records.

I think it do lock. And it set READ LOCKS.

> But if
> you call "select xyz from abc where ... for update of xyz" you will lock
> the records for updating.

Correct, this means you get WRITE locks.

Yes, this is way to control type of lock via SQL.
We also will get this way in 2.0.
For now we get it via API calls.

> If you are using Oracle*Forms, this will be done automatically.
> So you write a select and this data is shown in Forms. When
> the user changes a field this record is automatically locked for writing.

This is called "optimistic" record locking.
Records are not locked when cursor is built, IN HOPE that later you will be
able lock a record when you need.

Valentina for now implement "pessimistic" record locking.

Usually DBMS support both ways.

> But if the user now goes to eat something and will come back in an hour or
> so, the record is locked the whole time. so it is better not to show the
> real cursor but an internal list with the selected data. And if the user
> changes something make a short call with "update xyz from abc where ...".

-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------