Closed
Bug 580240
Opened 15 years ago
Closed 15 years ago
Executing multiple async statements creates an immediate transaction even for read statements
Categories
(Core :: SQLite and Embedded Database Bindings, defect)
Core
SQLite and Embedded Database Bindings
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: mak, Assigned: mak)
References
Details
Attachments
(1 file)
1.47 KB,
patch
|
Details | Diff | Splinter Review |
when we do dbConn.asyncExecute(statements, ...) storage creates an immediate transaction (http://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageAsyncStatementExecution.cpp#564), this causes a RESERVED lock to be acquired immediately on the database, regardless when the first write will be executed.
So in case we have 4 statements and the first 2 are read-only the database is locked without a reason for about half of the time.
We should use DEFERRED for now, see https://bugzilla.mozilla.org/show_bug.cgi?id=563538#c40
Assignee | ||
Comment 1•15 years ago
|
||
Assignee | ||
Comment 2•15 years ago
|
||
asking blocking to reduce statements locking contentions from bug 563538. one-line change with low known risk.
blocking2.0: --- → ?
Updated•15 years ago
|
blocking2.0: ? → final+
Comment 3•15 years ago
|
||
(In reply to comment #0)
> when we do dbConn.asyncExecute(statements, ...) storage creates an immediate
> transaction
> (http://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageAsyncStatementExecution.cpp#564),
> this causes a RESERVED lock to be acquired immediately on the database,
> regardless when the first write will be executed.
> So in case we have 4 statements and the first 2 are read-only the database is
> locked without a reason for about half of the time.
However, the RESERVED lock is for the sqlite3 object, so that means any statement executed on it, regardless of the thread, can execute. We aren't being locked out by the transaction here, but rather by the serialization.
This fix won't change anything as far as I can tell because transactions are per sqlite3 object, not per thread.
Assignee | ||
Comment 4•15 years ago
|
||
SQLite docs are not crystal clear about this point, they say there can only be 1 reserved lock _at a time_ (http://www.sqlite.org/lockingv3.html#reserved_lock), so if anything other requires a reserved lock (to write) it will hang waiting to be able to acquire one even if the async statement is reading. So, from what I get in docs, if the awesomebar gets a reserved lock, and some other statements wants to get a reserved lock to write, it would hang.
Can you clarify with someone from sqlite team? unless you already did.
Comment 5•15 years ago
|
||
Yes, but the connection gets the reserved lock, and all access to the connection is serialized. SQLite does not have the concept of locks per thread.
Comment 6•15 years ago
|
||
Confirmed with drh that what I'm saying is correct. As a result, I'm going to WONTFIX this.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Updated•15 years ago
|
Attachment #459518 -
Flags: review?(sdwilsh)
Updated•6 months ago
|
Product: Toolkit → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•