Lachlan Hunt wrote:
Both Minefield and Webkit trunk are failing those tests for me. I have
all but one commented out just so it would make my debugging easier (see
lines 287 to 292 in 002.html).
Oh, I'd just missed the one failing test. Showing only failing tests
helped!
I just checked in
It appears that Database, SQLTransactionCallback,
SQLTransactionErrorCallback, SQLVoidCallback, SQLTransaction,
SQLStatementCallback, and SQLStatementErrorCallback interfaces can all
be eliminated from WebDatabase completely.
Given WebWorkers and DatabaseSync, why do we need the Database ob
On Fri, Jul 24, 2009 at 4:45 PM, Nikunj R. Mehta wrote:
> I am not proposing to take away your choice. But please don't take away
> mine.
>
> It would be useful to see an explanation as to why the proposal I made
> [[
> add an isolation level parameter with a default value of SERIALIZABLE and
> rem
On Fri, Jul 24, 2009 at 5:32 PM, Nikunj R. Mehta wrote:
> The spec is also silent about what happens if I put a wait by making another
> asynchronous call inside my transaction callback logic. By inference, this
> would be allowed since all statements are executed inside callbacks, so why
> disting
On Jul 24, 2009, at 4:58 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 4:45 PM, Nikunj R. Mehta> wrote:
No. The transaction is not closed on GC, it is closed when the last
statement that is part of the transaction completes. So holding a
reference to the tx variable does nothing one way or t
On Fri, Jul 24, 2009 at 4:45 PM, Nikunj R. Mehta wrote:
>> No. The transaction is not closed on GC, it is closed when the last
>> statement that is part of the transaction completes. So holding a
>> reference to the tx variable does nothing one way or the other. The
>> only way to hang the transact
On Jul 24, 2009, at 4:25 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 4:12 PM, Nikunj R. Mehta> wrote:
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
2. create single-instance-only apps , i.e., hold a write lock on
the
database forever since they don't want to deal version checks.
On Fri, Jul 24, 2009 at 4:30 PM, Nikunj R. Mehta wrote:
>
> On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
>
>> In some models (non-SQL) it may be easier to
>> arrange a large update in the application layer and commit it all at
>> once. In SQL, this is less true so it is important to provide AP
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
I do not agree that database-level locking is a big problem for web
applications.
Our problem is not with databases doing database-level locking. Our
problem
is that such behavior is a MUST.
I think it is very desirable for it to appear t
On Fri, Jul 24, 2009 at 4:12 PM, Nikunj R. Mehta wrote:
>
> On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
>
>>> 2. create single-instance-only apps , i.e., hold a write lock on the
>>> database forever since they don't want to deal version checks.
>>
>> I don't think you understand the spec - i
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
So you are
reduced to very awkward ways of cooperating -- using the database
itself as a queue or for master election, or designing a separate
transaction system between tabs which might be on separate threads,
using an asynchronous API. Or you
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
2. create single-instance-only apps , i.e., hold a write lock on the
database forever since they don't want to deal version checks.
I don't think you understand the spec - it isn't actually possible to
hold the lock forever.
It is a little i
On Jul 24, 2009, at 3:11 PM, Ian Hickson wrote:
On Fri, 24 Jul 2009, Nikunj R. Mehta wrote:
On Jul 24, 2009, at 2:53 PM, Ian Hickson wrote:
These are very different from concurrency bugs.
There are only three concurrency "bugs"
1. The Lost Update Problem
2. The Temporary Update (or Dirty R
On Fri, Jul 24, 2009 at 2:54 PM, Nikunj R. Mehta wrote:
>
> On Jul 24, 2009, at 2:06 PM, Aaron Boodman wrote:
>
>> On Fri, Jul 24, 2009 at 1:54 PM, Nikunj R. Mehta
>> wrote:
>>>
>>> Experience has shown that there is no easy way out when dealing with
>>> transactions, and locking at the whole datab
If you want to provide an application programmer with a limited degree
of freedom from a certain class of errors, then there is a different
solution. It is called isolation level [1]. When opening a
transaction, just provide the required isolation level. Heck, if you'd
like, make "SERIALIZA
On Fri, 24 Jul 2009, Nikunj R. Mehta wrote:
> On Jul 24, 2009, at 2:53 PM, Ian Hickson wrote:
> >
> > These are very different from concurrency bugs.
>
> There are only three concurrency "bugs"
>
> 1. The Lost Update Problem
> 2. The Temporary Update (or Dirty Read) Problem
> 3. The Incorrect Su
On Jul 24, 2009, at 2:53 PM, Ian Hickson wrote:
These are very different from concurrency bugs.
There are only three concurrency "bugs"
1. The Lost Update Problem
2. The Temporary Update (or Dirty Read) Problem
3. The Incorrect Summary Problem.
Neither of these is related to the granularit
On Fri, 24 Jul 2009, Aaron Boodman wrote:
>
> I can't find the actual spec right now (where is its canonical home
> now?) so I can't point at the exact text, but that is the goal I
> believe.
The current home is:
http://dev.w3.org/html5/webdatabase/
--
Ian Hickson U+1047E
On Jul 24, 2009, at 2:06 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 1:54 PM, Nikunj R. Mehta> wrote:
Experience has shown that there is no easy way out when dealing with
transactions, and locking at the whole database level is no
solution to
failures.
The thing that makes the web bro
On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
>
> Let me probe this further to get clarity.
>
> > As I understand it, with what is specced now, if you try to get a
> > write transaction lock, it will only fail if it times out, which would
> > probably be a symptom of a more serious bug
On Fri, Jul 24, 2009 at 2:17 PM, Nikunj R. Mehta wrote:
>
> On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote:
>
>> On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
>>>
>>> That is all the responsibility of database system. We don't need to
>>> tell database systems on how to do it, we just ne
On Jul 24, 2009, at 1:36 AM, Ian Hickson wrote:
On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
That is all the responsibility of database system. We don't need to
tell database systems on how to do it, we just need to tell them on
what
to do. Today database systems do have lock m
On Fri, Jul 24, 2009 at 2:06 PM, Aaron Boodman wrote:
> I do not agree that database-level locking is a big problem for web
> applications.
Preemptive correction: I mean for the client-side of web applications.
There are usually at most a handful of clients accessing an HTML5
database instance.
-
On Fri, Jul 24, 2009 at 1:54 PM, Nikunj R. Mehta wrote:
> Experience has shown that there is no easy way out when dealing with
> transactions, and locking at the whole database level is no solution to
> failures.
The thing that makes the web browser environment different an
interesting is that mul
On Jul 23, 2009, at 6:24 PM, Ian Hickson wrote:
On Thu, 16 Jul 2009, Nikunj R. Mehta wrote:
The spec should not restrict implementations to any one level of
concurrency unless there are specific undesirable effects.
Restricting the database to a single writer means that if there are
separat
Hi Robin, All,
Why is the Widgets 1.0: URI Scheme about URI and not IRI?
Widgets 1.0 P&C is using only the term/type IRI (URI cannot be found there),
e.g. for id, href and name attributes.
In Widgets 1.0: URI Scheme (WUS?) document you refer in [1] to zip-rel-path.
It resembles IRI per design, s
Boris Zbarsky wrote:
Lachlan Hunt wrote:
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.
I'm glad to try to figur
Lachlan Hunt wrote:
I've also begun to add tests for the namespace selector syntax [2] to
the second set, but they are currently a work in progress and are not
functioning properly. If anyone can figure out what I've done wrong,
please let me know.
I'm glad to try to figure that out, if you
Hi,
I've made some progress with the test suite.
I have now split the test suite up into 3 files, similar to how I
prevoiusly described [1]:
1. Baseline Tests: HTML with CSS Level 2.1 Selectors.
2. Additional Tests: HTML with Selectors Level 3.
3. Additional Tests: XHTML+SVG with Selectors L
Let me probe this further to get clarity.
[Ian] >> As I understand it, with what is specced now, if you try to get a
write transaction lock, it will only fail if it times out, which would probably
be a symptom of a more serious bug anyway.
[Ian] >> There's never going to be a forced rollback;
On Fri, 24 Jul 2009, Laxmi Narsimha Rao Oruganti wrote:
>
> That is all the responsibility of database system. We don't need to
> tell database systems on how to do it, we just need to tell them on what
> to do. Today database systems do have lock manager which takes care of
> these responsibi
That is all the responsibility of database system. We don't need to tell
database systems on how to do it, we just need to tell them on what to do.
Today database systems do have lock manager which takes care of these
responsibilities.
Coming to the question of failing transaction unpredict
32 matches
Mail list logo
