Jay Sprenkle wrote:
On 1/21/07, Andrew Teirney <[EMAIL PROTECTED]> wrote:
I appologise in advance if this is not the correct place to post this
query ...
I was just wondering whether there might be any particular reason why
there doesn't appear to be support for creating transactions that
acquire a shared lock on execution of the BEGIN statement?
What is a 'shared' lock? You can't share a lock, only one process can
own it
at a time.
As per this document
http://www.sqlite.org/lockingv3.html
SHARED The database may be read but not written. Any number of processes
can hold SHARED locks at the same time, hence there can be many
simultaneous readers. But no other thread or process is allowed to write
to the database file while one or more SHARED locks are active.
/* Opcode: Transaction P1 P2 *
**
** Begin a transaction. The transaction ends when a Commit or Rollback
** opcode is encountered. Depending on the ON CONFLICT setting, the
** transaction might also be rolled back if an error is encountered.
**
** P1 is the index of the database file on which the transaction is
** started. Index 0 is the main database file and index 1 is the
** file used for temporary tables.
**
** If P2 is non-zero, then a write-transaction is started. A RESERVED
lock is
** obtained on the database file when a write-transaction is started. No
** other process can start another write transaction while this
transaction is
** underway. Starting a write transaction also creates a rollback
journal. A
** write transaction must be started before any changes can be made to the
** database. If P2 is 2 or greater then an EXCLUSIVE lock is also obtained
** on the file.
**
** If P2 is zero, then a read-lock is obtained on the database file.
*/
BEGIN IMMEDIATE creates the following opcode(s)
Transaction <n> 1
BEGIN EXCLUSIVE creates the following opcode(s)
Transaction <n> 2
BEGIN SHARED attempts to create the following opcode(s), i found no
other way of creating a transaction where a read-lock is obtained on the
database, by read-lock i suggest that means a SHARED lock based on my
experiments.
OP_Transaction <n> 0
So as you can see i feel there is a gap in that one cannot create a
transaction which acquires the SHARED (read-only) lock at the execution
of a BEGIN statement. This is what the addition of the SHARED
transaction type attempts to address.
CU,
Andrew
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
