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

On Thu, Jun 10, 2010 at 12:31 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Thu, Jun 10, 2010 at 8:13 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Jun 10, 2010 at 11:48 AM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> > On Thu, Jun 10, 2010 at 6:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> >>
>> >> On Thu, Jun 10, 2010 at 6:31 AM, Andrei Popescu <andreip@google.com>
>> >> wrote:
>> >> > On Thu, Jun 10, 2010 at 1:39 PM, Jeremy Orlow <jorlow@chromium.org>
>> >> > wrote:
>> >> >> Splitting into its own thread since this isn't really connected to
>> >> >> the
>> >> >> new
>> >> >> Async interface and that thread is already pretty big.
>> >> >>
>> >> >> On Wed, Jun 9, 2010 at 10:36 PM, Mikeal Rogers
>> >> >> <mikeal.rogers@gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> I've been looking through the current spec and all the proposed
>> >> >>> changes.
>> >> >>>
>> >> >>> Great work. I'm going to be building a CouchDB compatible API on
>> >> >>> top
>> >> >>> of IndexedDB that can support peer-to-peer replication without
>> >> >>> other
>> >> >>> CouchDB instances.
>> >> >>>
>> >> >>> 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.

> On Thu, Jun 10, 2010 at 8:02 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Thu, Jun 10, 2010 at 12:00 PM, Mikeal Rogers <mikeal.rogers@gmail.com>
>> wrote:
>> > Ah, good point. I hadn't thought about just using postMessage in my
>> > ontransactioncommitted, that'll work. Thanks.
>>
>> Except, how do you get a reference to the other windows that are
>> affected? There is no API to enumarate all windows that uses a given
>> site, much less all windows that are using a given database.
>
> Is there any particular reason this was never specced?

Don't know. It would mean that it's impossible to have several windows
for the same site running in different processes. Which I think all
current multiprocess browsers do today.

> (Or some sort of broadcast wasn't specced?)

That might be easier. Though ideal is of course if we can fire
appropriate events directly from IndexedDB, as long as we can do it
without perf impact.

/ Jonas

Received on Thursday, 10 June 2010 20:28:08 UTC