RE: [IndexedDB] Event on commits (WAS: Proposal for async API changes)

From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
Sent: Thursday, June 10, 2010 1:27 PM
Subject: Re: [IndexedDB] Event on commits (WAS: Proposal for async API changes)

>> >> >>> One of the things that will entail is a by-sequence index for all
>> >> >>> the
>> >> >>> changes in a give "database" (in my case a database will be scoped
>> >> >>> to
>> >> >>> more than one ObjectStore). In order to accomplish this I'll need
>> >> >>> to
>> >> >>> keep the last known sequence around so that each new write can
>> >> >>> create
>> >> >>> a new entry in the by-sequence index. The problem is that if
>> >> >>> another
>> >> >>> tab/window writes to the database it'll increment that sequence and
>> >> >>> I
>> >> >>> won't be notified so I would have to start every transaction with a
>> >> >>> check on the sequence index for the last sequence which seems like
>> >> >>> a
>> >> >>> lot of extra cursor calls.
>> >> >>
>> >> >> It would be a lot of extra calls, but I'm a bit hesitant to add much
>> >> >> more
>> >> >> API surface area to v1, and the fall back plan doesn't seem too
>> >> >> unreasonable.
>> >> >>
>> >> >>>
>> >> >>> What I really need is an event listener on an ObjectStore that
>> >> >>> fires
>> >> >>> after a transaction is committed to the store but before the next
>> >> >>> transaction is run that gives me information about the commits to
>> >> >>> the
>> >> >>> ObjectStore.
>> >> >>>
>> >> >>> Thoughts?
>> >> >>
>> >> >> To do this, we could specify an
>> >> >> IndexedDatabaseRequest.ontransactioncommitted event that would
>> >> >> be guaranteed to fire after every commit and before we started the
>> >> >> next
>> >> >> transaction.  I think that'd meet your needs and not add too much
>> >> >> additional
>> >> >> surface area...  What do others think?
>> >> >
>> >> > It sounds reasonable but, to clarify, it seems to me that
>> >> > 'ontransactioncommitted' can only be guaranteed to fire after every
>> >> > commit and before the next transaction starts in the current window.
>> >> > Other transactions may have already started in other windows.
>> >>
>> >> We could technically enforce that other transactions won't be allowed
>> >> to start until the event has fired in all windows that has the
>> >> database open.
>> >
>> > Sure, but I can't think of any reason you'd want such semantics.  Can
>> > you?
>>
>> I'm not entirely sure what the requirements are, so not sure.
>>
>> If the requirement is that you are always notified about changes to a
>> table before those changes start affecting reads, so that you can keep
>> some separate information in sync, then we need to block further
>> transactions until the event has been fired in all relevant windows.
>
> This would only make sense if all the oncommit handlers were started in
> their own transaction so that you could at least read data.  Otherwise all
> you know is that something changed--so you wouldn't really have much to go
> on for the goal of "keep[ing] some separate information in sync".  Or you'd
> then have to schedule a transaction which wouldn't necessarily run before
> other stuff is updated which means there was no point for us to block
> transactions on everyone being notified anyway.  The only reason I can think
> of why it'd matter is if your app was doing synchronization via other means
> as well, but I can't immediately think of any places where waiting on all to
> be notified would save you, even then.
>>
>> Possibly it would be ok to allow windows that has already received the
>> transaction to start reading the updated data though. That should make
>> this have virtually no performance impact.
>
> We should think VERY carefully about anything that has a perf impact.  But
> what I originally suggested should have a small one at worst, I would think.
>
>>
>> But yes, we should definitely figure out what the actual requirements are.
>
> Agreed.
>>
>> >> Either way though, I'm wondering how this relates to the fact that you
>> >> can (in our proposal, I'm unclear what the current draft allows) have
>> >> several writing transactions at the same time, as long as they operate
>> >> on different tables. Here another transaction might have already
>> >> started by the time another transaction is committed. Be that in this
>> >> window or another.
>> >
>> > That's only true of dynamic transactions.
>>
>> That isn't true in at least our proposal (again, I'm unclear what the
>> current draft allows). In our proposal you can have multiple static
>> write transactions in progress at the same time. As long as they don't
>> overlap in which objectStores they use.
>
> I was assuming the sequence number would be stored in a single objectStore.

>Ah, I see what you mean. Good point.

>Mikeal, could you describe in detail how you were planning on using this event.

We should drill more into the actual requirements. I would be really weary of introducing constructs that require cross-process coordination outside of the database itself. To me blocking a window from making progress until another window finishes work (which may take a while) seems to be a candidate to cause trouble (even if you don't block the UI thread the application maybe stuck waiting for the database before it lets the user interact again). Also for scenarios such as synchronization allowing concurrent transactions is important, which makes the events not be enough, as other overlapping transactions may be making changes while you're firing a commit; even reading the seq number at the beginning of the transaction won't do, as that would cause all sequent overlapping transactions to block on the "seq number row".

I suspect that this may be the kind of thing that we'll need to do in the database itself if we want to enable the scenario, or it'll result in unreliable layers on top that do their best but just don't have the means to achieve a robust implementation. 

-pablo

Received on Thursday, 10 June 2010 23:23:40 UTC