Nullable<PersistenceType> only allows to specify a concrete persistence type or
all persistence types while PersistenceScope is intended to allow specification
of multiple persistence types as well. Support for that will be added in a
separate patch. This patch is about using the new type especially in directory
locks.
Differential Revision: https://phabricator.services.mozilla.com/D195373
One of the goals of the asynchronous temporary storage initialization is to
call Ensure(Persistent|Temporary)OriginIsInitialized only from
Initialize(Persistent|Temporary)OriginOp. Calling from other places including
quota clients will be disallowed by changing the method to a private method.
The private nature of the method should be emphasized by adding the Internal
suffix.
Differential Revision: https://phabricator.services.mozilla.com/D192150
Maintenance::Abort and DatabaseMaintenance::Abort should not drop any directory
locks. Only Maintenance::Finish and DatabaseMaintenance::RunOnOwningThread are
responsible for cleanup activities like this.
The directory lock for initial collection of databases held by Maintenanace is
normally dropped by BeginDatabaseMaintenance, but if something fails (in any
method), Maintenance::Finish will do the cleanup.
Differential Revision: https://phabricator.services.mozilla.com/D215088
It can happen that DirectoryOpen call in Maintenance::DirectoryLockAcquired
fails or Maintenance::DirectoryWork method fails or
Maintenance::BeginDatabaseMaintenance method fails which results in
Maintenance::Finish being called with not null mDirectoryLock and that
the directory lock hasn't been dropped in Maintenance::BeginDatabaseMaintenance.
Maintenance::Finish should always check and eventually drop the directory lock
instead of relying on Maintenance::BeginDatabaseMaintenance to drop it.
We still want to drop it as soon as possible in
Maintenance::BeginDatabaseMaintenance so other storage operations are not
blocked by the directory lock covering all idb folders for all repositories.
Differential Revision: https://phabricator.services.mozilla.com/D214388
Until now, directory locks were dropped when the last strong reference was
removed or after calling Drop explicitly. The dependency on ref-counting makes
it less obvious when directory locks are dropped for real and it's also
difficult to release them asynchronously eventually. This patch removes the
directory lock unregistration from the destructor, so from now on, directory
locks must be always dropped explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D197294
Have idleThreadGraceTimeout and idleThreadMaximumTimeout instead of just idleThreadTimeout.
Clarify that idleThreadMaximumTimeout is only affecting allowed idle threads.
Make idle threads end only after at minimum idleThreadGraceTimeout even if they are in excess.
Remove the idleThreadTimeoutRegressive setting.
Introduce a "most recently used" priority for notifying idle threads to
avoid excessive round-robin through all available idle threads.
The management of the linked list has constant time, adding thus only
minimal overhead wrt to the previous wasIdle flags we had.
As a side effect (and coming from the investigations in bug 1891732) to
some extent this can help to improve the "logical thread affinity",
together with trying to keep events dispatched with NS_DISPATCH_AT_END
on the dispatching thread as much as possible, which should help
TaskQueue a lot with affinity.
Differential Revision: https://phabricator.services.mozilla.com/D209884
With this patch, IDB connection pool begins to run transactions and idle maintenance on task queue event targets on top of a thread pool. The underlying thread pool will take over all thread management.
Differential Revision: https://phabricator.services.mozilla.com/D191296
With this patch, IDB connection pool begins to run transactions and idle maintenance on task queue event targets on top of a thread pool. The underlying thread pool will take over all thread management.
Differential Revision: https://phabricator.services.mozilla.com/D191296
Explicitly committed transactions are aborted in case of a failed request. This
is achieved by tracking order of requests. The order of requests is currently
tracked by storing request serial numbers. However, request serial numbers are
not always in sync between parent and child, so they are only suitable for
logging purposes. This patch switches from request serial numbers to request
ids which are only generated by the child side and thus always in sync between
parent and child.
Differential Revision: https://phabricator.services.mozilla.com/D204200
This patch adds only new member variables, actual support for sending ids will
be added in individual patches (all ids are set to zero for now). The idea is
to have only one source of truth, so an id used in the parent and child is
always the same.
Differential Revision: https://phabricator.services.mozilla.com/D204025
In case we did start a DeleteFilesRunnable before shutdown we should ensure it is going to be executed before we leave our QM shutdown barrier, but we can ignore pending but not yet started deletions completely as PBM origins are deleted entirely by other means.
Differential Revision: https://phabricator.services.mozilla.com/D203502
Previously, idle maintenance was interrupted whenever a new runnable was
posted to the executing thread. Here we replace this interrupt signal with
an explicit boolean flag in order to support task queue event targets.
Differential Revision: https://phabricator.services.mozilla.com/D165984
Previously, idle maintenance was interrupted whenever a new runnable was
posted to the executing thread. Here we replace this interrupt signal with
an explicit boolean flag in order to support task queue event targets.
Differential Revision: https://phabricator.services.mozilla.com/D165984
