Thread: Server side session management using the SQLite (per session) database

Hi Dave/team,

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.

Murtuza,

I have tested it on Python 2.7.

Can you please take a look at it, and do the needful to make it work on Python 3.x?

Hi

On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

Hi Dave/team,

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)?

 

Murtuza,

I have tested it on Python 2.7.

Can you please take a look at it, and do the needful to make it work on Python 3.x?

Please double-check Windows as well.

Thanks. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Hi,

I just tested the latest code under windows environment with python 2.7 which is working fine without any errors.

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi 

Thanks,

Neel Patel

On Wed, Mar 23, 2016 at 1:02 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

On Tue, Mar 22, 2016 at 8:41 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

Hi Dave/team,

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.

Thanks. 

I assume it's expected at this point that new connections still fail if the backend is restarted (that would come with graceful reconnections)?

Hmm..

I did not get that.

Do you mean to say?

- New Connection to the server should not be established (if it was restarted).

- What about the existing connection, should it re-establish the connection after the backend restart (when allowed)?

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

 

Murtuza,

I have tested it on Python 2.7.

Can you please take a look at it, and do the needful to make it work on Python 3.x?

Please double-check Windows as well.

Thanks - Murtuza for the python 3 support patch. 

Neel - can you please take a look at the Windows?

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi

Thanks. 

--

Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Tue, Mar 22, 2016 at 8:41 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

Hi Dave/team,

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.

Thanks. 

I assume it's expected at this point that new connections still fail if the backend is restarted (that would come with graceful reconnections)?

Hmm..

I did not get that.

Do you mean to say?

- New Connection to the server should not be established (if it was restarted).

- What about the existing connection, should it re-establish the connection after the backend restart (when allowed)?

Hi

On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

Hi Dave/team,

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)?

 

On Tue, Mar 22, 2016 at 4:11 PM, Dave Page <dpage@pgadmin.org> wrote:

Hi

On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:

Hi Dave/team,

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 :)

Not saying it's wrong, absolutely not. Just expect a few laughs coming off that one :D

--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company

http://www.linkedin.com/in/asheshvashi 

--

 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Wed, Mar 23, 2016 at 9:04 AM, Magnus Hagander <magnus@hagander.net> wrote:
>
>
> On Tue, Mar 22, 2016 at 4:11 PM, Dave Page <dpage@pgadmin.org> wrote:
>>
>> Hi
>>
>> On Thu, Mar 17, 2016 at 5:46 PM, Ashesh Vashi
>> <ashesh.vashi@enterprisedb.com> wrote:
>>>
>>> Hi Dave/team,
>>>
>>> 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 :)

It's actually been there for ages - we just now store session info in
it as well as config settings.

> Not saying it's wrong, absolutely not. Just expect a few laughs coming off
> that one :D

I'm aware of the irony :-). It's a perfectly fine embedded database
though, and that's what we needed here. Running a Postgres instance
for this is severe overkill - but I don't need to explain that to you.