Use sqlite_close_v2()

[rinzevdwalAlfen]

Use sqlite3_close_v2() instead of sqlite3_close(). Since we use the close in a destructor and and a destructor shoudn't fail. We should use the sqlite3_close_v2() instead since it will automatically deallocate the database connection after all prepared statements are finalized, all BLOB handles are closed, and all backups have finished.

sqlite_close documentation

[valentin-dimov]

To my understanding, this change would mean that we won't get error prints from the destructor, even if the database is busy - however, sqlite_close_v2 will not wait for in-progress work to finish, it will simply arrange for the connection to be cleaned up whenever the work is done. If we call close_connection right before shutting down (which is, I assume, the main use-case), it seems to me that this could still lead to the process exiting with a dirty connection, since we never actually wait for the database connection to be destroyed.

[rinzevdwalAlfen]

The documentation states

If sqlite3_close_v2() is called with unfinalized prepared statements, unclosed BLOB handlers, and/or unfinished sqlite3_backups, it returns SQLITE_OK regardless, but instead of deallocating the database connection immediately, it marks the database connection as an unusable "zombie" and makes arrangements to automatically deallocate the database connection after all prepared statements are finalized, all BLOB handles are closed, and all backups have finished. The sqlite3_close_v2() interface is intended for use with host languages that are garbage collected, and where the order in which destructors are called is arbitrary.

So I am not sure if you are correct when stating that the sqlite_close_v2 will not wait for in-progress work to finish. Since it will finalize all prepared statements.

On the other hand with sqlite_close as we do now. The call will return SQLITE_BUSY and not close the connection.

[valentin-dimov]

I'm not particularly familiar with sqlite3, but reading the doc page, I'm not sure that when it says the function "makes arrangements to automatically deallocate the database connection after all prepared statements are finalized [...]", this means the function blocks until that work is finished. Is it possible it'll return early and the work continues in the background?

[valentin-dimov]

Following our discussion: looks good, noting that we still need to look into why we were getting busy errors before, as those are still unexpected.

[Dominik-K]

The DatabaseHandler deconstructor used the sqlite3_close_v2() until one month ago until PR

• Database error handling #247

So it's ok to get back to this state.

However, it would be good to reflect this in OCPP 1.6, too. Seems that the DatabaseHandler itself could be a generic one.

[Dominik-K]

However, it would be good to reflect this in OCPP 1.6, too. Seems that the DatabaseHandler itself could be a generic one.

Tracked in

• DatabaseHandler: consolidate more functions to ...Base #359