On 11/6/07, John Firebaugh <[EMAIL PROTECTED]> wrote:
> > You're confusing threads with the context of the connection. When you
> > call sqlite3_open() you get a single connection to a db. That
> > connection can then be used across threads, but it is for all intents
> > and purposes a single
Richard Klein wrote:
John Firebaugh wrote:
I take it this mean that if, say, thread A begins a transaction, and
modifies the database, then thread B modifies the database, then thread
A commits the transactions, B's modifications are also committed?
Nope. Once thread A begins a transaction,
> John Firebaugh wrote:
> > I take it this mean that if, say, thread A begins a transaction, and
> > modifies the database, then thread B modifies the database,
> then thread
> > A commits the transactions, B's modifications are also committed?
>
> Nope. Once thread A begins a transaction, no
John Firebaugh wrote:
I take it this mean that if, say, thread A begins a transaction, and
modifies the database, then thread B modifies the database, then thread
A commits the transactions, B's modifications are also committed?
Nope. Once thread A begins a transaction, no other thread (or
A transaction state is dependent upon the lock state, and the lock is at
database level because the database is the resource being shared by user
initiated connections. Locks are held by individual connections and
those connections can be at process or thread level.
The Sqlite locks are
> Note that your example of two threads attempting to update the same
> record at the same time is consistent with this theory -- in
> either case SQLITE_BUSY (or similar) is likely to occur on one of the
> threads.
I see now that I am also likely wrong about this. In the shared
connection
> You're confusing threads with the context of the connection. When you
> call sqlite3_open() you get a single connection to a db. That
> connection can then be used across threads, but it is for all intents
> and purposes a single line of communication with a database (using it
> twice at the
On Nov 6, 2007 7:45 PM, John Firebaugh <[EMAIL PROTECTED]> wrote:
> "Restrictions on the use of the same database connection by multiple
> threads have been dropped. It is now safe for multiple threads to use
> the same database connection at the same time." This suggests to me that
> operations
> > I would have expected the "no transaction
> > nesting" restriction to be enforced per-thread, not per-connection.
>
> And what made you believe so? How is supporting nested transactions in
> multiple threads any easier than supporting them in a single thread?
I have no idea; the main
John Firebaugh
wrote:
With SQLite 3.5.1, when a connection is shared between two threads, if
the second thread attempts to begin a transaction while a transaction
is
in progress on the first thread, sqlite3_exec( "begin transaction" )
returns SQLITE_ERROR with a status message "cannot start a
10 matches
Mail list logo
