On Thu, Jun 10, 2010 at 6:31 AM, Andrei Popescu <andr...@google.com> wrote: > On Thu, Jun 10, 2010 at 1:39 PM, Jeremy Orlow <jor...@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.rog...@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. 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. / Jonas
