1140826 - mozStorage should correctly process SQLITE_ABORT/SQLITE_ABORT_ROLLBACK(introduced by spec change in SQLite 3.7.11), and shouldn't convert it to NS_ERROR_FAILURE, because SQLite 3.7.17 was already used in Fx 24.0 at 2013/09 and 3.8.8.2 is currently used

Status: NEW

(Toolkit :: Storage, defect, P3)

Description

[WADA:World Anti-bad-Duping Agency]

+++ This bug was initially created as a clone of Bug #1062823 +++
This is spin-off of bug 1062823 comment #8.

mozStorage should correctly process SQLITE_ABORT_ROLLBACK/SQLITE_ABORT(introduced by spec change in SQLite 3.7.11), and shouldn't convert it to NS_ERROR_FAILURE, because SQLite 3.7.17 was already used in Fx 24.0 at 2013/09 and 3.8.8.2 is currently used

Comment 1

[WADA:World Anti-bad-Duping Agency]

Possible data loss:
   transaction from task #1 gets update-lock of row-droup-AA, gets write-lock of row-A
   if contention occurs on update-lock of row-droup-AA, SQLITE_BUSY is returned to transaction from task #2,
   then transaction from  task #2 issues ROLLBACK and retries request.
   if the ROLLBACK is processed before completion of transaction from task #1, SQLITE_ABORT is returned to transaction from task #1,
   then transaction from task #1 issues ROLLBACK because COMMIT can not be issued due to error return code.
   If the ROLLBACK is requested while ROLLBACK by task #2 is in progress, SQLITE_ABORT_ROLLBACK is returned to ROLLBACK by task #1.
   Curent mozStorage Rollback() code doesn't retry ROLLBACK when SQLITE_ABORT_ROLLBACK(retry only whe SQLITE_BUSY).
   SQLITE_ABORT_ROLLBACK is currently converted to NS_ERROR_FAILURE.
   If localStorage.setItem(), localStorage won't retry request upon NS_ERROR_FAILURE.
   So, update is lost, and write-lock of the row-A won't be released, even when localStorage(always single row update except clear).

Comment 2

[WADA:World Anti-bad-Duping Agency]

Actually reported problem at a forum is;
  When localStorage is used, SQLITE_BUSY happens in localStorage.clear() once per several days if application is heavily used.
   SQLITE_BUSY was hooked by try{localStorage.clear();}catch(e){ ... }
  This "SQLITE_BUSY in localStorage.clear()" won't disappear until restart of Firefox.
I can't imagine other than "unreleaed lock for a row" in this case, because almost all update request is localStorage.setItem/localStorage.removeItem which is always single "Inset Or Replace" for single row only.
And, phenomenon of Comment #1 can happen, if I correctly understand code and NSPR log.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.