Bug 48425

Summary: Clean up IDBTransactionBackend/Coordinator
Product: WebKit Reporter: Jeremy Orlow <jorlow>
Component: New BugsAssignee: Jeremy Orlow <jorlow>
Status: RESOLVED FIXED    
Severity: Normal CC: andreip, hans, steveblock
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
patch
none
a steveblock: review+

Jeremy Orlow
Reported 2010-10-27 06:27:22 PDT
.
Attachments
patch (17.86 KB, patch)
2010-10-27 06:45 PDT, Jeremy Orlow
no flags
a (18.44 KB, patch)
2010-10-27 09:00 PDT, Jeremy Orlow
steveblock: review+
Jeremy Orlow
Comment 1 2010-10-27 06:45:39 PDT
Andrei Popescu
Comment 2 2010-10-27 07:10:17 PDT
>IDBTransactionBackendImpl::~IDBTransactionBackendImpl() > { > abort(); Now that the coordinator doesn't keep a ref to the transaction backends, are we guaranteed to work as expected in the following scenario: db.transaction().objectStore("foo").put(...); window.gc(); If the transaction frontend object gets destroyed, it will unref it's backend object, which may abort the transaction before it's got the chance to do the work?
Jeremy Orlow
Comment 3 2010-10-27 08:25:36 PDT
(In reply to comment #2) > >IDBTransactionBackendImpl::~IDBTransactionBackendImpl() > > { > > abort(); > > Now that the coordinator doesn't keep a ref to the transaction backends, are we guaranteed to work as expected in the following scenario: > > db.transaction().objectStore("foo").put(...); > window.gc(); > > If the transaction frontend object gets destroyed, it will unref it's backend object, which may abort the transaction before it's got the chance to do the work? You're right. Actually, I think this largely isn't a problem as currently written.
Jeremy Orlow
Comment 4 2010-10-27 09:00:22 PDT
Andrei Popescu
Comment 5 2010-10-27 09:11:38 PDT
LGTM > PassRefPtr<IDBTransactionCoordinator> IDBTransactionCoordinator::create() > { > return adoptRef(new IDBTransactionCoordinator()); > } Why is this in the cpp now? > m_transactions.add(transaction, transaction); Heh :)
Jeremy Orlow
Comment 6 2010-10-27 09:23:41 PDT
(In reply to comment #5) > LGTM > > > PassRefPtr<IDBTransactionCoordinator> IDBTransactionCoordinator::create() > > { > > return adoptRef(new IDBTransactionCoordinator()); > > } > > Why is this in the cpp now? We do it both ways. More often we do it in the .h, but I really think it's cleaner to do it in the cpp files. My intention is to do it this way throughout. > > m_transactions.add(transaction, transaction); > > Heh :)
Steve Block
Comment 7 2010-11-01 11:39:23 PDT
Comment on attachment 72041 [details] a View in context: https://bugs.webkit.org/attachment.cgi?id=72041&action=review > WebCore/storage/IDBTransactionCoordinator.h:63 > + HashMap<IDBTransactionBackendImpl*, RefPtr<IDBTransactionBackendImpl> > m_transactions; Using a map like this seems a little odd. Can't you just use a HashSet? If required, you could provide a custom HashFunctions to make sure the value of the raw pointer is used when looking up a value.
Jeremy Orlow
Comment 8 2010-11-02 04:22:10 PDT
(In reply to comment #7) > (From update of attachment 72041 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=72041&action=review > > > WebCore/storage/IDBTransactionCoordinator.h:63 > > + HashMap<IDBTransactionBackendImpl*, RefPtr<IDBTransactionBackendImpl> > m_transactions; > > Using a map like this seems a little odd. Can't you just use a HashSet? If required, you could provide a custom HashFunctions to make sure the value of the raw pointer is used when looking up a value. I'm pretty sure I'd have to create some custom version that handles the keys being ref pointers. Is it really worth the effort to do this? Does it really make it that much more clean? Maybe just a fixme is enough so the tradeoff is documented?
Steve Block
Comment 9 2010-11-02 06:15:58 PDT
Comment on attachment 72041 [details] a View in context: https://bugs.webkit.org/attachment.cgi?id=72041&action=review >>> WebCore/storage/IDBTransactionCoordinator.h:63 >>> + HashMap<IDBTransactionBackendImpl*, RefPtr<IDBTransactionBackendImpl> > m_transactions; >> >> Using a map like this seems a little odd. Can't you just use a HashSet? If required, you could provide a custom HashFunctions to make sure the value of the raw pointer is used when looking up a value. > > I'm pretty sure I'd have to create some custom version that handles the keys being ref pointers. Is it really worth the effort to do this? Does it really make it that much more clean? Maybe just a fixme is enough so the tradeoff is documented? Sure, I guess a FIXME is OK. I think it's worth a quick try though - I didn't read through all of HashSet, but I think it might just work with RefPtr.
Jeremy Orlow
Comment 10 2010-11-05 07:01:56 PDT
Note You need to log in before you can comment on or make changes to this bug.