[Webkit-unassigned] [Bug 27966] Race condition in the database code

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Dumitru Daniliuc <dumi at chromium.org>  2009-08-07 22:39:13 PDT ---
(In reply to comment #11)
> 51         typedef Deque<RefPtr<SQLTransaction> > TransactionsQueue;
> 52         typedef HashMap<String, TransactionsQueue*> TransactionsHashMap;
> 53         OwnPtr<TransactionsHashMap> m_pendingTransactions;
> 
> Can you use an OwnPtr<TransactionsQueue> in the HashMap to avoid any manual
> cleanup in the dtor? When the TransactionsHashMap is deleted i think it would
> all be properly deleted and deferenced.
> 
> Also, can TransactionHashMap be an inline data member instead of held in an
> OwnPtr?

After a long discussion with Michael, we decided to make TransactionsHashMap an
inline data member. However, we couldn't find a good way to wrap
TransactionsQueues inside the hash map into a smart pointer. Any suggestions
here?

> 91     // Remove 'transaction' from the queue of pending transactions
> 92     // 'transaction' should always be the first transaction in this queue
> 93     ASSERT(pendingTransactions->first().get() == transaction);
> 94     pendingTransactions->removeFirst();
> 
> Just checking... are there any circumstanaces where a waiting transaction can
> run thru its 'fail' sequence and call releaseLock() early?

Again, after some investigation with Michael, we found a case where a
transaction might fail before it even acquires a lock (Database::stop() is
called after scheduling the first step of a transaction on the DB thread, but
before the DB thread has a chance to start the task). So we added a
m_lockAcquired flag to SQLTransaction.

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