[DO NOT REVIEW] Added wal with shared cache

[tiensi]

Summary

There seems to be a WAL race condition within the builder.rs file where a session is created and get session immediately after, which in some instances can fail because the read session is looking at an old version of the sessions db + WAL page from one thread before the write session commit finishes propagating.

I believe the culprit to be the lack of an explicit "commit" transaction with WAL enabled. In the concurrency section of sqlite documentation, When a read operation begins on a WAL-mode database, it first remembers the location of the last valid commit record in the WAL. So even though we were relying on concurrency through await?; the commit never applied.

This could also explain why the Pragma wal_checkpoint approach didn't work as the checkpoint didn't have a completed commit to apply WAL file changes to the database.

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

AI Assistance

• This PR was created or reviewed with AI assistance

Testing

I was unable to reproduce on multiple linux docker images, I went ahead and reproduced the "bug" (create_session and get_session race condition) by writing concurrent create_session -> get_session race condition tests and ran them a few thousand times.

Related Issues

Relates to #5197
Discussion:

• Previous fix

[tiensi]

different approach here