As discussed, I have implemented the server side session management using the SQLite database.
Implementation:
* It creates/reuses the sqlite database per session.
* Stores the key (as text)/value (as blob) in the sqlite database.
* Needs to provide the session directory, where you want to store those sessions. If this directory does not exist, it creates the directory with 700 permission. (Default: <USER_HOME>/.pgadmin/sessions directory.)
* Also - sets default value for the log file to be stored in the '<USER_HOME>/.pgadmin' directory. This will allow us to keep separate configuration per user on any operation system, when running through runtime.
This implementation uses sqlite as session storage, it may affect because of explicit file system I/O operation. Though - performance should not be a big issue, as we're not targeting to support very huge parallel sessions.
Thanks - applied.
I assume it's expected at this point that new connections still fail if the backend is restarted (that would come with graceful reconnections)?
Heh, does this actually make sqlite a dependency for pgadmin4? That's kind of hilarious :)
:)
We're already using sqlite for saving the local configurations instead of flat file, which caused a lot of problem in past with pgAdmin 3.
Not saying it's wrong, absolutely not. Just expect a few laughs coming off that one :D
Do not have time to implement another database. :P