NoLocks // 1.9.8b10 adoption of record locks. Feedback

[erne]

on 4-07-2003 20:59, Ruslan Zasukhin at sunshine at public.kherson.ua wrote:

>> this way the use of cursors will be reduced to a take-the-data-and-run mode
>> i.e. you MUST release the cursor ASAP to avoid the entire system to be
>> clogged
>> up
> 
> YES !!!
> 
> If you develop something multi-user you need follow rule
> 
> make transactions AS SHORT AS POSSIBLE in time,
> and select as FEW records as possible. In ideal just one.
> 
> 
> Big DBMS do not like query as "SELECT * FROM T"  :-)
> 

Well, I understand this is cool for tight security

but the cost is: 
say goodbye to quasi-instant record selections that we were used to
I mean we have to store those data somewhere
and this will surely produce overhead

> Not, that if you work with server and ask for client cursor (which is always
> read only) then you get copy of records to you local computer and records
> are unlocked. 
> 
> Also if you make read only cursor DBMS can decide (or in future we will get
> option) create on SERVER side TMP table with result of query, so main table
> can be released.
> 

this is cool, but of course writing to file will take time
(and data may become out-of-date very soon)



Cool Runnings,
Erne.

-- 
|  e r  |  Ernesto Giannotta
|  n e  |  Musical Box - a media store