John Firebaugh <john_firebaugh-C69GFqk2Qz/[EMAIL PROTECTED]>
wrote:
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 attraction of SQLite is it frees me from
having
to worry about such difficulties. From a _user's_ perspective, rather
than an implementer's perspective, it seems a reasonable assumption:
"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."
Ok, that means that something that used to only work for a single thread
now also works for multiple threads. How does this lead you to assume
that a feature that did _not_, and still does not, work in a single
thread, would suddenly start working in multiple threads?
Obviously two threads can issue commands that change the database at
the
same time
No. You are still required to synchronize access, so only one thread
uses the connection at any given time. If you don't, it will likely lead
to database corruption. Pretty much the only benefit of sharing a
connection between threads is reduced memory footprint due to the fact
that memory cache is also shared: if you have two separate connections,
and each has recently retrieved the same page from database file, you
would have two copies of this page in memory, but if you have one
connection you only have one copy.
Igor Tandetnik
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
