Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
I'm glad to hear that somebody has been working on this issue!
After read your proposal and previous dicussion, I realized that such
locking mechanism doesn't have to be tied to specific storage mechanism,
and a promise-based API
is more general than a synchronous API.
在 2015年07月16日 01:12, Joshua Bell 写道:
Based on similar feedback, I've been noodling on this too. Here are my
current thoughts:
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
Feedback welcome - I was planning to send this around shortly anyway.
On Wed, Jul 15, 2015 at 3:07 AM, 段垚 duan...@ustc.edu
mailto:duan...@ustc.edu wrote:
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 {
localStorage.lock('file1.html');
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?
Regards,
Duan Yao
Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
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 {
localStorage.lock('file1.html');
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?
Regards,
Duan Yao
Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
Based on similar feedback, I've been noodling on this too. Here are my
current thoughts:
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
Feedback welcome - I was planning to send this around shortly anyway.
On Wed, Jul 15, 2015 at 3:07 AM, 段垚 duan...@ustc.edu wrote:
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 {
localStorage.lock('file1.html');
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?
Regards,
Duan Yao
Re: Cross-page locking mechanism for indexedDB/web storage/FileHandle ?
Yeah, I think a standalone primitive for asynchronous atomics. The
big risk is of course that deadlocks can occur, but there's no real
way to completely avoid that while keeping a flexible platform. These
deadlocks would be asynchronous, so no thread will hang, but you can
easily end up with two pages looking hung to the user.
The best thing that I think we can do to help here is to enable pages
to issue a single function call which grabs multiple locks.
We could also enable registering a callback which is called when the
platform detects a deadlock. However we won't always be able to detect
deadlocks, so I'm not sure that it's a good idea.
I also don't have enough experience to know which atomics are worth
exposing, and which ones we should leave to libraries.
/ Jonas
On Wed, Jul 15, 2015 at 10:12 AM, Joshua Bell jsb...@google.com wrote:
Based on similar feedback, I've been noodling on this too. Here are my
current thoughts:
https://gist.github.com/inexorabletash/a53c6add9fbc8b9b1191
Feedback welcome - I was planning to send this around shortly anyway.
On Wed, Jul 15, 2015 at 3:07 AM, 段垚 duan...@ustc.edu wrote:
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 {
localStorage.lock('file1.html');
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?
Regards,
Duan Yao
