On Wed, Nov 12, 2008 at 8:46 AM, Hernán Rodriguez Colmeiro <[EMAIL PROTECTED]> wrote: > And what happens when the user moves away from the page that created > the worker? > I mean, suppose that the user was in page A (the one that created the > worker) but before the worker finished it's job, the user moves to > page B (may be in the same server or not). What happens then with the > worker? Is it killed and any possible transaction is rolled back or > that just happens on tab/browser close?
By move away do you mean navigate the tab to a different URL? The way we have specified the feature (in both Gears and HTML5) navigation is the same as quitting the browser. In Gears, on page unload (or tab renavigation), we allow the worker to finish processing the message it was in the middle of, even if it takes a really long time. Any queued messages are dropped on the floor. In HTML5, the current message continues processing on page unload, but only for a "user-defined amount of time", which would probably be on the order of a few seconds. After that, the worker is uncerimoniously killed. This is important because otherwise a worker could keep itself alive forever if it were in an infinite loop, which is actually an open bug on the Gears implementation. Browser shutdown is a special case in Gears. I'm honestly not sure if the current message gets to finish executing. I suspect it may be a race condition. In all cases, Gears (and HTML5) will never leave a transaction open on page unload or browser shutdown. The design of most (all?) databases is that you have to actually commit a transaction to have anything be visible to other clients of the database or stick around permanently. If you never call commit (because, say, the browser crashed), the transaction basically never occurred. Stepping back, I think it's important for web apps to not rely on getting to finish one last bit of work on unload. It is impossible to guarantee that this last bit of work will get done, eg in the case of a browser crash or system power down. So it's better to just write your app with the understanding that unload may never occur. HTH, - a
