web sql database in web worker
187 views
Skip to first unread message
Paul
Feb 11, 2012, 5:20:38 PM2/11/12
to gwt-mobile-webkit-users, paul....@kirona.com
Hello,
I have used the code from the Speed Tracer product to create a web
worker in GWT. So far so good. I've sent a simple message and got the
worker to post something back to test and this all works fine. The
modules I inherit for my web worker module are:
<inherits name='com.google.gwt.core.Core' />
<inherits name="com.google.gwt.webworker.WebWorker" />
I now want to get my web worker to use the database api
http://code.google.com/p/gwt-mobile-webkit/wiki/DatabaseApi which
according to the html5 specification a web worker can access local
databases.
So in my web worker module I now also inherit:
<inherits name="com.google.code.gwt.database.Html5Database" />
If I examine the generated javascript it has references to $doc and
$wnd in it so I can't see how this can ever work inside a worker since
a worker does not have access to the Window or Document objects (Yes I
am using the using the primary dedicatedworker linker defined in the
WebWorker module)
For an example a call to openDatabase is $wnd.openDatabase
I chnaged the javascript to $self.openDatabase (and other references)
and it worked.
The $doc references do not cause an issue for some reason. It is in a
javascript fiunction that looks like it is checking the user agent
being used $doc.documentMode etc
Any ideas how to fix?
As a side note looks like the gwt eclipse plugin (along with browser
in dev mode) does not support break points etc. That's a pain coz you
can't even do window.alert etc I wonder if GWT.log will work?
I have used the code from the Speed Tracer product to create a web
worker in GWT. So far so good. I've sent a simple message and got the
worker to post something back to test and this all works fine. The
modules I inherit for my web worker module are:
<inherits name='com.google.gwt.core.Core' />
<inherits name="com.google.gwt.webworker.WebWorker" />
I now want to get my web worker to use the database api
http://code.google.com/p/gwt-mobile-webkit/wiki/DatabaseApi which
according to the html5 specification a web worker can access local
databases.
So in my web worker module I now also inherit:
<inherits name="com.google.code.gwt.database.Html5Database" />
If I examine the generated javascript it has references to $doc and
$wnd in it so I can't see how this can ever work inside a worker since
a worker does not have access to the Window or Document objects (Yes I
am using the using the primary dedicatedworker linker defined in the
WebWorker module)
For an example a call to openDatabase is $wnd.openDatabase
I chnaged the javascript to $self.openDatabase (and other references)
and it worked.
The $doc references do not cause an issue for some reason. It is in a
javascript fiunction that looks like it is checking the user agent
being used $doc.documentMode etc
Any ideas how to fix?
As a side note looks like the gwt eclipse plugin (along with browser
in dev mode) does not support break points etc. That's a pain coz you
can't even do window.alert etc I wonder if GWT.log will work?
Paul
Feb 14, 2012, 4:24:20 AM2/14/12
to gwt-mobile-webkit-users
As a workaround I have added:
$wnd = self;
$doc = {};
$doc.compatMode = 'CSS1Compat';
...to the top of the DedicatedWorketTemplate.js (in package
com.google.gwt.webworker.linker) so I do not have to manually fix the
generated javascript after a GWT compile.
$wnd = self;
$doc = {};
$doc.compatMode = 'CSS1Compat';
...to the top of the DedicatedWorketTemplate.js (in package
com.google.gwt.webworker.linker) so I do not have to manually fix the
generated javascript after a GWT compile.
Bart Guijt
Feb 14, 2012, 5:55:13 PM2/14/12
to gwt-mobile-...@googlegroups.com
That is quite a crude workaround you're showing :-)
Having said that, I'll have to dig around to find a solution myself -- for which I don't have time right now...
Apart from this problem, are you aware that the Web Database API is removed from the HTML5 agenda? It is to be replaced with 'IndexedDB' which is kinda like a LocalStorage API on steroids (inc. transaction support).
Having said that, this API should work just fine in your case. There is a bug somewhere.
Bart Guijt
> --
> You received this message because you are subscribed to the Google Groups "gwt-mobile-webkit-users" group.
> To post to this group, send email to gwt-mobile-...@googlegroups.com.
> To unsubscribe from this group, send email to gwt-mobile-webkit...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gwt-mobile-webkit-users?hl=en.
>
Paul
Feb 15, 2012, 4:47:12 AM2/15/12
to gwt-mobile-webkit-users
Hello Bart,
yes it is crude but I am doing a quick POC and time is short as they
say :(
if the POC goes well then I will dig into the code and sort it.
Yes I know web database api is no longer maintained by w3c but it is
so much more easy to use then the indexeddb api when you have
relational data. Also I believe (but I admit information out there is
sketchy) that the indexeddb api is still patchy across browsers? Maybe
you know better?
The fundamental problem I am having now is that if I access the same
web sql database from the web worker (using async api) and the ui
thread (using async api) I sometimes get issues if transactions
overlap between the two where the transaction fails or is simply
bizarely skipped without error. I have assumed this is a webkit issue
since a web worker is totally sandboxed from the ui thread (apart from
the noddy messaging between the 2 you can do) in terms of javascript.
I am wondering if it is worth trying to use the sync api in the worker
thread (which has been implemented in webkit - the gwt-mobile-webkit
web site needs updating here since it states the opposite). It looks
straight forward to create a gwt sync database api in the worker which
again I can do? Any thoughts whether you think this will solve my
issue?
As far as I am aware SQLite supports concurrent access (but only 1
thread can write to the database at a time), but SQLite happily blocks
threads as needed so I do not see why it would be an issue accessing
the sqlite db from 2 threads (like I am doing).
If webkit has a bug I will need to report it and then also use a
different storage mechanism for the POC? Any ideas here as well? I'm
targeting mostly webkit type browsers (playbook, android, iphone etc)
Many thanks
yes it is crude but I am doing a quick POC and time is short as they
say :(
if the POC goes well then I will dig into the code and sort it.
Yes I know web database api is no longer maintained by w3c but it is
so much more easy to use then the indexeddb api when you have
relational data. Also I believe (but I admit information out there is
sketchy) that the indexeddb api is still patchy across browsers? Maybe
you know better?
The fundamental problem I am having now is that if I access the same
web sql database from the web worker (using async api) and the ui
thread (using async api) I sometimes get issues if transactions
overlap between the two where the transaction fails or is simply
bizarely skipped without error. I have assumed this is a webkit issue
since a web worker is totally sandboxed from the ui thread (apart from
the noddy messaging between the 2 you can do) in terms of javascript.
I am wondering if it is worth trying to use the sync api in the worker
thread (which has been implemented in webkit - the gwt-mobile-webkit
web site needs updating here since it states the opposite). It looks
straight forward to create a gwt sync database api in the worker which
again I can do? Any thoughts whether you think this will solve my
issue?
As far as I am aware SQLite supports concurrent access (but only 1
thread can write to the database at a time), but SQLite happily blocks
threads as needed so I do not see why it would be an issue accessing
the sqlite db from 2 threads (like I am doing).
If webkit has a bug I will need to report it and then also use a
different storage mechanism for the POC? Any ideas here as well? I'm
targeting mostly webkit type browsers (playbook, android, iphone etc)
Many thanks
Reply all
Reply to author
Forward
0 new messages