Open Bug 1140826 Opened 5 years ago Updated 3 years ago

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

Categories

(Toolkit :: Storage, defect, P3, critical)

36 Branch
defect

Tracking

()

People

(Reporter: World, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: dataloss, Whiteboard: [potential Data Loss])

User Story

Spec change of SQLite is still not reflected to code of Storage.
This bug exists since Firefox 24.0.
+++ 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
Blocks: 1062823
User Story: (updated)
No longer depends on: 1062823
Keywords: dataloss
Whiteboard: [Spec change of SQLite is still not reflected to code of Storage]
Version: 24 Branch → 36 Branch
Whiteboard: [potentially Data Loss]
Summary: 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 → 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
Whiteboard: [potentially Data Loss] → [potential Data Loss]
User Story: (updated)
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).
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.
Priority: -- → P3
No longer blocks: 1062823
Depends on: 1062823
You need to log in before you can comment on or make changes to this bug.