-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sqlite: Deleting a database previously referenced by a different connection string throws #25797
Comments
Notes from triage: this could be fixed in EF Core by clearing all pools before deleting the file. However, it might also make sense for M.D.Sqlite to handle connections to the same file in some way. |
Decision from triage: call ClearAllPools in EF. |
Reverted to get test runs working reliably again. |
A better fix might be to update the pooling code to use the same connection pool for the same database file as much as possible. In other words, it could normalize the path used in
|
Fixes #25797 Fixes #26016 I identified two race conditions, both caused by splitting state across multiple data structures. In particular, the Semaphore and the two ConcurrentStacks must stay in sync--that is, the Semaphore can let someone get a collection if and only if there is a connection available in the one of the stacks. The fix is to wrap all these things in a single lock. It's possible that we don't need a full lock, but we already have one to protect _collections which can easily be expanded to cover the right areas. Once this lock is used, the semaphore is no longer needed, and the stacks don't need to be concurrent because they are protected by the lock.
Fixes #25797 Fixes #26016 I identified two race conditions, both caused by splitting state across multiple data structures. In particular, the Semaphore and the two ConcurrentStacks must stay in sync--that is, the Semaphore can let someone get a collection if and only if there is a connection available in the one of the stacks. The fix is to wrap all these things in a single lock. It's possible that we don't need a full lock, but we already have one to protect _collections which can easily be expanded to cover the right areas. Once this lock is used, the semaphore is no longer needed, and the stacks don't need to be concurrent because they are protected by the lock.
I suspect this is because connection pooling still has a connection open for the database, but this is not discovered because the two connections use different connection strings. (One has Command Timeout set, the other does not.)
The text was updated successfully, but these errors were encountered: