T.R | Title | User | Personal Name | Date | Lines |
---|
136.1 | | JENEVR::CHELSEA | Mostly harmless. | Mon May 23 1988 16:55 | 9 |
| Re: .0
>Can we perform much better in the above situation?
Maybe. It depends on how the transaction is defined. If the relation
is reserved for SHARED access, if the index is used to retrieve
records, if the indexed field is not updated, if users update entirely
distinct sets of records - then yes, we can do much better. The
users would all have roughly the same response time on the commit.
|
136.2 | Not always Table Locking | KOKO::DAVIS | Outer Joins are Un-Natural | Tue May 24 1988 18:16 | 7 |
| I believe that ORACLE allows a finer level of granularity on locking
maybe record or page, by employing a SELECT FOR UPDATE syntax. I
also believe that the locking has been significantly revamped for
the 'TPS' version of ORACLE.
Sandy
|
136.3 | We should win in multi-user update as a general rule! | BANZAI::BERENSON | Rdb/VMS - Number ONE on VAX | Fri May 27 1988 15:03 | 5 |
| It does appear that you have to write your queries in a special way to
get record level locking with ORACLE. By the way "ORACLE*TPS", or
whatever they really call it when formally announced, gets its
performance by having you re-write your applications in a special
(incompatible?) variant of SQL.
|
136.4 | record level locking by default in V6 | DEBIT::FOLDEVI | | Fri May 27 1988 17:44 | 5 |
|
According to what was presented last fall at Oracle User conf, the
default locking level will be the record level in Version 6 of Oracle.
Table level is to be optional. I would assume that this applies
whether or not the new PL/SQL (procedural SQL) is used.
|