So, my understanding of this issue is that: `ConnectionPool::CloseDatabase()` [1] is called before the `PBackgroundIDBRequestParent* TransactionBase::AllocRequest()` [2] is called. For a read transaction that should be okay, but it becomes a problem in the case of a write transaction. The reason is that in the `Database::EnsureConnection()` [3], it only creates a read transaction when it can't find out a connection for the given database. Consequently, for instance, it would crash when it starts the autosave point in `ObjectStoreAddorPutRequestOp::DoDatabaseWork()`. My first impression for this is that I should check whether we can prevent the `connection` from being closed in this case and also check if we can either abort the operation or update the read transaction to the write transaction. For the "prevent the `connection` from being closed in this case": I check all the caller of the `CloseDatabase()`. And, all of them are executed because the idle timer (30s) is expired. It seems they are reasonable. For the "abort the operation or update the read transaction to the write transaction" - "Abort the operation" I hit the assertion for lacking `mStoreageConnection` [GetCachedStatement in 4] for the `Transaction` while the `Transaction` if I tried to abort the operation in TransactionDatabaseOperationBase::RunOnConnectionThread() (before ensuring the connection [5]). - "Update the read transaction to the write transaction" I hit the assertion for duplicating the key [6] if I tried to do that by calling BeginWriteTransaction() in `ObjectStoreAddorPutRequestOp::DoDatabaseWork()` [7]. It's a failure case for getting a constraint error of foreign key. It seems that part of the cached statement was rollbacked while closing the previous connection. [1] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#11510 [2] https://searchfox.org/mozilla-central/rev/6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/dom/indexedDB/ActorsParent.cpp#13797 [3] https://searchfox.org/mozilla-central/rev/6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/dom/indexedDB/ActorsParent.cpp#12503 [4] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#21886 [5] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#21564-21572 [6] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#24214 [7] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#23946
Bug 1528690 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So, my understanding of this issue is that: `ConnectionPool::CloseDatabase()` [1] is called before the `PBackgroundIDBRequestParent* TransactionBase::AllocRequest()` [2] is called. For a read transaction that should be okay, but it becomes a problem in the case of a write transaction. The reason is that in the `Database::EnsureConnection()` [3], it only creates a read transaction when it can't find out a connection for the given database. Consequently, for instance, it would crash when it starts the autosave point in `ObjectStoreAddorPutRequestOp::DoDatabaseWork()`. My first impression for this is that I should check whether we can prevent the `connection` from being closed in this case and also check if we can either abort the operation or update the read transaction to the write transaction. For the "prevent the `connection` from being closed in this case": I check all the caller of the `CloseDatabase()`. And, all of them are executed because the idle timer (30s) is expired. It seems they are reasonable. For the "abort the operation or update the read transaction to the write transaction" - "Abort the operation" I hit the assertion for lacking `mStoreageConnection` [GetCachedStatement in 4] for the `Transaction` while the `Transaction` is commiting if I tried to abort the operation in TransactionDatabaseOperationBase::RunOnConnectionThread() (before ensuring the connection [5]). - "Update the read transaction to the write transaction" I hit the assertion for duplicating the key [6] while executing the statement if I tried to do that by calling BeginWriteTransaction() in `ObjectStoreAddorPutRequestOp::DoDatabaseWork()` [7]. It's a failure case for getting a constraint error of foreign key. It seems that part of the cached statement was rollbacked while closing the previous connection. [1] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#11510 [2] https://searchfox.org/mozilla-central/rev/6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/dom/indexedDB/ActorsParent.cpp#13797 [3] https://searchfox.org/mozilla-central/rev/6db0a6a56653355fcbb25c4fa79c6e7ffc6f88e9/dom/indexedDB/ActorsParent.cpp#12503 [4] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#21886 [5] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#21564-21572 [6] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#24214 [7] https://searchfox.org/mozilla-central/rev/8d78f219702286c873860f39f9ed78bad1a6d062/dom/indexedDB/ActorsParent.cpp#23946