W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2015

Cross-page locking mechanism for indexedDB/web storage/FileHandle ?

From: 段垚 <duanyao@ustc.edu>
Date: Wed, 15 Jul 2015 18:07:24 +0800
Message-ID: <55A630DC.4070702@ustc.edu>
To: public-webapps@w3.org
Hi all,

I'm developing an web-based editor which can edit HTML documents locally 
(stored in indexedDB).
An issue I encountered is that there is no reliable way to ensure that 
at most one editor instance (an instance is a web page) can open a 
document at the same time.

* An editor instance may create a flag entry in indexedDB or 
localStorage for each opened document to indicate "this document is 
locked", and remove this flag when the document is closed. However, if 
the editor is closed forcibly, this flag won't be removed, and the 
document can't be opened any more!

* An editor instance may use storage event of localStorage to ask "is 
this document has been opened by any other editor instance". If there is 
no response for a while, it can open the document. However, storage 
event is async so we are not sure about how long the editor has to wait 
before opening the document.

* IndexedDB and FileHandle do have locks, but such locks can only live 
for a short time, so can't lock an object during the entire lifetime of 
an editor instance.

In a native editor application, it may use file locking 
(https://en.wikipedia.org/wiki/File_locking) to achieve this purpose.
So maybe it is valuable to add similar locking mechanism to 
indexedDB/web storage/FileHandle?

I propose a locking API of web storage:

   try {
     myEditor.open('file1.html'); // open and edit the document
   } catch (e) {
     alert('file1.html is already opened by another editor');

Storage.lock() lock an entry if it has not been locked, and throw if it 
has been locked by another page.
The locked entry is unlocked automatically after the page holding the 
lock is unloaded. It can also be unlocked by calling Storage.unlock().

What do you think?

Duan Yao
Received on Wednesday, 15 July 2015 10:08:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:57 UTC