When the thread is restarted, we do not know if we missed any payload. So we
must clear the cache and the pool to have a clean start.
issue11397
review431631003
We need to ensure that the listener is running on the return of the transaction
start otherwise notification can be missed.
We must also just from time to time check that the listener is still the
current listener.
And finally we can not wait an arbitrary time for cache sync, instead we must
rely on the _clean_last being reset with the sync happens.
issue9413
review364831002
We use default_factory to avoid create unnecessary instances. The
default_factory_with_key argument is added to LRUDict to pass the missing key
to the default_factory method. And we use an LRUDict also for the
Transaction.cache.
issue10726
review362531002
When a transaction is committed indeed a new transaction is started. So we do
not need to use a transaction cache just because a commit was sent because the
started_at is reset to a higher time.
This same logic applies to a rollback.
issue10528
review365521003
When a process change the list of activated modules, the others must refresh
their pool. We do that by just stopping the pool for that database, the next
request will load the new pool.
issue8988
review302861002
As we rollback the cache modification when loading a module, we must clear all
of them at the end to ensure to not keep outdated data.
issue9759
review339421002
By using a class with slots instead of standard dict, we can reduce a lot the
memory usage to store the record data in the caches and values.
Also we can rely on the data in the cache to exist only for real field which
can be used to create a fast path in ModelStorage.__getattr__.
As now storing data in the cache has no extra cost, we can store data from the
transactional cache in the local. This allow also to have a shorter path in
ModelStorage.__getattr__.
For more memory efficiency, we remove the record from the cache instead of
clearing them. It was better to clear a dict but a record is less expensive to
re-instantiate than clearing.
issue9369
issue9225
review297861002
On distributed setup, the cache is not synchronized instantaneously so we can
not use the cache if the record was modified by another process since the last
synchronisation.
issue9013
review262841002
The table is a hot spot for contention so we must minimize the duration lock
are kept on it. As at the start of a transaction, the cache may be sync and so
it locks all the row in the table, the transaction used for this query should
not be the main one that lasts a long time. Idem for the commit.
issue8447
review283591002
When the clear timeout of the cache is zero, we launch a thread to synchronize
caches if the back-end support channels.
The thread is started on the first call to sync for the database.
The channel is also used to clear the cache of the process initiating the
clearing. This allows to test the mechanism is working with a single process.
So there will be a small delay even on single instance.
issue8027
review68431002
We implement sync, commit and rollback to follow transaction semantic.
When a transaction clears a cache, the global cache is cleared only when the
transaction is committed meanwhile the transaction will use a cache for itself
only.
We remove _nocache option because the sync, commit and rollback operate only
for the transaction.
issue7975
review53521002
* Use python-sql
* Add convert_domain method on Fields
* Add sql_format and sql_type methods on Fields
* Allow to return a full domain for Function.searcher
* Replace static backend by dynamic get method
* Replace order_field by order_<field name> method
review1001002
Cédric Krier