[Webkit-unassigned] [Bug 46883] IDBDatabase::createObjectStore/removeObjectStore and IDBObjectStore::createIndex/removeIndex should be synchronous.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=46883





--- Comment #10 from Andrei Popescu <andreip at google.com>  2010-10-04 16:24:54 PST ---
(In reply to comment #9)
> (From update of attachment 69498 [details])
> 
> close
> 
> 
> View in context: https://bugs.webkit.org/attachment.cgi?id=69498&action=review
> 
> > LayoutTests/storage/indexeddb/objectstore-cursor.html:67
> > +    if (window.nextToAdd > 0)
> 
> hu?
> 

It's the same pattern used elsewhere for loading data into an object store.

> > LayoutTests/storage/indexeddb/resources/shared.js:82
> > +    onfinished();
> 
> ugh!  I'm so stupid...I just made this change...should have realized it's worthless (and not made the change in my last patch).  Maybe put in a FIXME to make this function sync and not do a callback like this.
> 

Added.

> > WebCore/storage/IDBDatabaseBackendImpl.cpp:191
> > +    RefPtr<IDBTransactionBackendInterface> rpTransaction = transaction;
> 
> transactionPtr...here and elsewhere
> 
> > WebCore/storage/IDBIndexBackendImpl.cpp:55
> > +    , m_id(0)
> 
> use a constant instead of 0 maybe?
> 
> > WebCore/storage/IDBIndexBackendImpl.h:52
> > +    int64_t id() const { return m_id; }
> 
> ditto to all comments below
>

You mean above? Done.

> > WebCore/storage/IDBObjectStoreBackendImpl.cpp:335
> > +    transaction->didCompleteTaskEvents();
> 
> Wait...why do we need this?  Isn't this implicit whenever a task's events finish?
> 

It isn't. These tasks don't have any events.

> > WebCore/storage/IDBObjectStoreBackendImpl.h:55
> >      int64_t id() const { return m_id; }
> 
> Assert the id is valid maybe?  ...here and everywhere that id is used?
> 

Asserting.

> Please put in a comment here describing the subtleties of this..and how stuff using id should only be queued asyncly.
> 
> We should put a fixme or actual code into the transaction coordinator to make sure that it blocks any transactions on this object store on this current transaction finishing....
>


Yep, that should happen once we have a thread per transaction and we will implement locking. The object store will be locked until the setVersion transaction commits, thereby guaranteeing that no other transaction can use its backend while it has the invalid ID.


> > WebCore/storage/IDBTransactionBackendImpl.cpp:146
> > +void IDBTransactionBackendImpl::taskEventTimerFired(Timer<IDBTransactionBackendImpl>*)
> 
> Hm...this still seems a bit fragile...but I guess it's good enough for now.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.