Google Colab VM Lifecycle and SQLAlchemy Connection Pool Interaction

Goal: guarantee that database connections borrowed from a connection pool are properly returned to the pool before the underlying Colab virtual machine is reclaimed, preventing leaked connections and pool exhaustion.

Constraint: Colab notebooks run on temporary VMs that may be recycled after approximately ninety minutes of inactivity or when the runtime is reset, and the platform does not expose a pre‑shutdown hook for user code. The interaction between this VM lifetime, the pool’s idleTimeout setting, and the behavior of a factory reset on open TCP sockets is not documented, leaving designers unsure whether relying on pool timeouts alone is sufficient or whether explicit disposal per cell is required.

Specific questions: Does a Colab factory reset immediately terminate open TCP sockets, or do they persist until the operating system’s TCP keep‑alive times out? Should the pool’s idleTimeout be configured to match the expected VM lifetime, or must connections be explicitly closed at the end of each notebook cell to avoid accumulation? Is there a reliable signal within the notebook that indicates an imminent VM recycle so that a shutdown hook can be triggered?