List pagination locking for state-data changes

Changed semantics of locking: instead of relying of locking running-db,
an automatic lock bound to a session is maintained. When the session closes
the lock is released.
This commit is contained in:
Olof hagsand 2021-10-28 14:49:33 +02:00
parent 197fc16e69
commit eea6d549f6
5 changed files with 25 additions and 19 deletions

View file

@ -309,15 +309,16 @@ pagination_limit(pagination_data pd)
return ((pagination_data_t *)pd)->pd_limit;
}
/*! Get pagination data: locked parameter
/*! Get pagination data: locked parameter for state data
*
* Pagination can use a lock/transaction mechanism
* If locking is not used, the plugin cannot expect more pagination calls, and no state or
* caching should be used
* If locking is used, the pagination is part of a session transaction and the plugin may cache
* state (such as a cache) and can expect more pagination calls until the running db-lock is
* released, (see ca_lockdb)
* The transaction is the regular lock/unlock db of running-db of a specific session.
* A "paginate" lock is set for a specific session when list-pagination is in progress.
* If locking is set, the pagination is part of a session transaction and the plugin may
* cache state (such as a cache) and can expect more pagination calls until the "paginate"
* db-lock is released.
*
* If you want to do the same for config data, it is recommended to use lock-db on
* the appropriate database, but this risks of indefinite blocking, as long as the
* session endures.
* @param[in] pd Pagination userdata
* @retval locked 0: unlocked/stateless 1: locked by this caller
*/