W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: FW: [indexeddb] transaction commit failure

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 22 Aug 2011 17:26:43 -0700
Message-ID: <CA+c2ei_vP3fdL2BfY8v+Uf92Ynxnr8WJK0-7E9k3DHUJaMmN+w@mail.gmail.com>
To: Eliot Graff <Eliot.Graff@microsoft.com>
Cc: Israel Hilerio <israelh@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Tom Bolds <thombo@microsoft.com>, Adam Herchenroether <aherchen@microsoft.com>, Victor Ngo <vicngo@microsoft.com>, "me@shawnwilsher.com" <me@shawnwilsher.com>
We should also explicitly mention that canceling the event (by calling
preventDefault) does *not* prevent the transaction from being aborted.

/ Jonas

On Mon, Aug 22, 2011 at 2:27 PM, Eliot Graff <Eliot.Graff@microsoft.com> wrote:
> I added a step 3 to 4.3 Steps for committing a transaction:
>
> 3. If an error occurs while committing the transaction, fire an error event with type set to UNKNOWN_ERROR, and then follow the steps for aborting a transaction.
>
> Thanks,
>
> Eliot
>
>> -----Original Message-----
>> From: public-webapps-request@w3.org [mailto:public-webapps-
>> request@w3.org] On Behalf Of Jonas Sicking
>> Sent: Wednesday, August 17, 2011 4:56 PM
>> To: Israel Hilerio
>> Cc: public-webapps@w3.org; Tom Bolds; Adam Herchenroether; Victor Ngo;
>> me@shawnwilsher.com
>> Subject: Re: FW: [indexeddb] transaction commit failure
>>
>> On Wed, Aug 17, 2011 at 3:08 PM, Israel Hilerio <israelh@microsoft.com>
>> wrote:
>> > On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote:
>> >> On Monday, August 15, 2011, Shawn Wilsher <me@shawnwilsher.com>
>> wrote:
>> >> > On 8/15/2011 3:31 PM, Israel Hilerio wrote:
>> >> >>
>> >> >> When the db is doing a commit after processing all records on the
>> >> >> transaction, if for some reason it fails, should we produce an
>> >> >> error event first and let the bubbling produce a transaction abort
>> >> >> event or should we only produce a transaction abort event. It
>> >> >> seems that doing the first approach would be more complete.
>> >> >
>> >> > I agree; the first approach seems better and I can't think of any reason
>> why it would be difficult to implement.
>> >> >
>> >> > The catch is that calling `preventDefault` will not prevent the abort,
>> which is (I think) different from how we handle other errors, right?
>> >>
>> >> Yeah, I'm tempted to say that that is enough of a reason for simply firing
>> abort directly, but I could be convinced otherwise.
>> >>
>> >> / Jonas
>> >
>> > We would like to follow the first approach because it allows us to notify the
>> developer that there was an error on the transaction and that is the reason
>> the transaction was aborted.
>>
>> Ok, that works for me.
>>
>> / Jonas
>>
>
>
Received on Tuesday, 23 August 2011 00:27:49 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT