As sessions in pgAdmin4 are filesystem based session, they need locking
for avoiding the access from multiple threads, specially running as an
WSGI application.
Fixes#3547
This issue was caused because we recently added session_write_delay in session.
So session won't be written/updated to disk from memory until specified seconds are elapsed.
However we must forcefully write/update session to disk if user loges in or out irrespective of session_write_delay to keep sessions from memory and disk in sync as user logged in status is kept in session.
Session object is updated, everytime a request is being served, and
that was forcing the session object dumped on the dist on every request.
On windows, it was causing issues on slower system on startup. Because -
windows file system locks the file, when it is opened by any
application. And, frequent requests on the pgAdmin main UI rendering
was causing issues, because of that.
In order to resolve the issue, we will not write the session data on
disk for every request, but - only after certain delay (in seconds),
from it was last written. It can be configured using the attribute
'PGADMIN_SESSION_DISK_WRITE_DELAY' in the configuration file,
default vaule for the delay is 10.
(i.e. 10 seconds)
In order to resolve the non-ascii characters in path (in user directory,
storage path, etc) on windows, we have converted the path into the
short-path, so that - we don't need to deal with the encoding issues
(specially with Python 2).
We've resolved majority of the issues with this patch.
We still need couple issues to resolve after this in the same area.
TODO
* Add better support for non-ascii characters in the database name on
windows with Python 3
* Improve the messages created after the background processes by
different modules (such as Backup, Restore, Import/Export, etc.),
which does not show short-paths, and xml representable characters for
non-ascii characters, when found in the database objects, and the file
PATH.
Fixes#2174, #1797, #2166, #1940
Initial patch by: Surinder Kumar
Reviewed by: Murtuza Zabuawala
optimized to work from multiple threads. It has too many frequent
transaction from multiple threads, and that tends to result into the
'database is locked' error of sqlite.
With the new implemenation, we're using the caching mechanism, which
keep the data in the memory all the time, and saves it on request
completion, and loads it only for the first time. Also, it will storage
the data using pickle, which will be faster than accessing sqlite.
Fixes#1329
