Repository navigation
Explicit GC.gc() needed for SQLite.DB to become really out of scope. #285
Description
Otherwise at the end of program execution sqlite database remains in use by Julia REPL.
And according to the doc: "The SQLite.DB will be automatically closed/shutdown when it goes out of scope (i.e. the end of the Julia session, end of a function call wherein it was created, etc" - turns out not true!
Link to JuliaLang discussion of the problem:
https://discourse.julialang.org/t/sqlite-database-remains-in-use-by-julia-repl/77194
Activity
quinnj commentedon Apr 14, 2022
Hi @MarieJC, thanks for opening an issue! Yeah, this is somewhat a general Julia "destructor" problem as we're relying on the
finalizerfunctionality in Julia, which allows you to register a function that runs when an object is garbage collected. But the problem is, as you noted, it's not well-defined when objects actually get garbage-collected!Do note that you can always call
close(db)or more generallyDBInterface.close!(db)to force a database connection to be closed, which we should probably highlight in the docs as the proper way to manage the lifetime resource of your sqlite database connection.MarieJC commentedon Apr 14, 2022
Thank you for your response! Yes, DBInterface.close!(db) works. But in my particular exercise the code operating on a db isspread between diff functions - so it is tricky to close the db at the very end. This is not a priority though!!! We were just testing out similar functionality in several languages, including Julia.
quinnj commentedon Sep 30, 2026
The docs now say this plainly: a finalizer eventually closes an unreachable
SQLite.DB, but its timing isn't guaranteed. For deterministic cleanup, callclose(db)(orDBInterface.close!(db)), ideally intry/finally(#359). Starting with the next release,close(db)also finishes any statements that were abandoned but not yet garbage-collected (#362), so nothing stays locked or commits later.