[Webkit-unassigned] [Bug 29115] Allow multiple read transactions to run concurrently on the same DB thread

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29115





--- Comment #19 from Dumitru Daniliuc <dumi at chromium.org>  2009-09-21 14:42:47 PDT ---
(In reply to comment #18)
> The SQLTransactionCoordinator logic LGTM, much clearer.
> 
> My first look at the layout tests...
> 
> // Hack: wait for these transactions to finish running before terminating the
> test
> Is this empty transaction guaranteed to finish last?

It is (because it is a write transactions, and the transaction coordinator will
wait for all other transactions to finish executing before scheduling this
one), but it is a pretty hacky way to assert termination.

> The two new layout tests start <n> transactions back to back. Would a valid way
> to wait for completion be to observe <n>th completion callback and signal
> 'done' at that point? Something like bump a  'transactionsStarted' count prior
> to calling db.transaction() or readTransaction(), and bump a
> 'transactionComplte' count in the success callback, and test if (started ==
> complete) for done'ness.

replaced the hack in both layout tests with something nicer.

> Incidentally, unrelated to this patch, looks like sync Database.tableNames()
> method is a wedge-ladden land-mine waiting to get stepped on. Runs a select
> statement without an explicit transaction, so that puts the statement in an
> implicit transaction. Depending on the lock applied to the file, and on the
> connection which holds that lock... this can wedge the system.
> Database.tableNames() is only used by the inpspector, so webapp code can't get
> wedged by this, but the inspector can.

you're right, we (or somebody else?) will have to take a look at this at some
point.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.