Can jupyter server use a third-party database to store sessions, and how?

[xiangzhetianlumaijing]

Multiple jupyter servers need to share sessions.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[kevin-bates]

Hi @xiangzhetianlumaijing - thanks for opening this issue.

I don't think SQLite lends itself to this use case. Seems like introducing an ORM layer like SQLAlchemy would be a great first step. This way, more powerful, multi-user, multi-server, databases can be configured w/o impacting the application layer (theoretically).

I believe we'd be open to this kind of contribution given that we're trying to evolve the server in this fashion anyway.

[xiangzhetianlumaijing]

Thanks for your answer. Can multiple jupyter servers share the same sqlite? How to configure the IPs and ports' information of sqlite?

[kevin-bates]

My (limited) understanding is that SQLite is an embedded database meaning that it's only available to a single process/application. I believe others have tried having multiple applications share the same database file, but have run into issues (I believe I've run across SO posts of this nature), probably because you really need a service to manage concurrency and locking at that level (like more powerful databases provide).

If we had an abstraction layer, perhaps as thin as something like SQLAlchemy, then users should be able to swap out the database provider behind the abstraction layer.

[xiangzhetianlumaijing]

Thanks.

[kevin-bates]

@xiangzhetianlumaijing - we discussed this in our server meeting and I've opened a general discussion issue. I encourage you to follow (and participate) in these discussions. We'd love to hear from you.

I'm going to close this issue since it was more of a question that has been answered (albeit not necessarily what you wanted to hear). Hopefully, we can address things in a more productive manner down the road.