On Thu, Jun 10, 2010 at 11:48 AM, Jeremy Orlow <jor...@chromium.org> wrote: > On Thu, Jun 10, 2010 at 6:15 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> 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. > > 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. 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. But yes, we should definitely figure out what the actual requirements are. >> 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. / Jonas
