Database connection management #261

Merged

sirdog3355 merged 1 commit from refact/db-connections into dev

2026-03-06 22:29:04 -05:00

sirdog3355 commented

2026-03-06 22:28:45 -05:00

(Migrated from github.com)

Wow. That was... a lot.

So, as mentioned in #253, my database connection management was very poor. I followed what worked, but it working was mostly because this is a very low traffic Discord bot and sqlite3 is very forgiving.

Things improved:

All database connections now explicitly open and close, whether via a context manager (short-lived connections) or global management in main.py (long-lived connections).
For long lived connections, usage of the sqlite3 cursor is handled per-method to mitigate against a situation where 2 different methods want to use the same cursor at the same milisecond, which may cause threading violations.
Long lived connections have check_same_thread set to False to allow the same connection to be used anywhere in the bot, mitigating against lock conflicts.
Short lived connections now use a context manager (e.g with CLASS_NAME as db...) throughout rather than initiating the class per cog, which is what caused the leaked connections

This should improve stability considerably.

Closes #253

Wow. That was... a lot. So, as mentioned in #253, my database connection management was very poor. I followed what worked, but it working was mostly because this is a very low traffic Discord bot and `sqlite3` is very forgiving. Things improved: - All database connections now explicitly open and close, whether via a context manager (short-lived connections) or global management in `main.py` (long-lived connections). - For long lived connections, usage of the `sqlite3` cursor is handled per-method to mitigate against a situation where 2 different methods want to use the same cursor at the same milisecond, which may cause threading violations. - Long lived connections have `check_same_thread` set to `False` to allow the same connection to be used anywhere in the bot, mitigating against lock conflicts. - Short lived connections now use a context manager (e.g `with CLASS_NAME as db...`) throughout rather than initiating the class per cog, which is what caused the leaked connections This should improve stability considerably. Closes #253