-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Sqlite3 not threadsave when db is in memory #2875
Comments
have same issue. |
@xmlking do you think the issue is related to gorm or sqlite itself? |
Indeed
Work fine with a file |
So whats the protocol here? Shall I make A PR with the failing test? |
Any update on this? |
See this issue in go-sqlite3: mattn/go-sqlite3#204 This is likely caused by If you want multiple connections to share the same DB, open the DB with |
Thanks for the reply, I'll test as soon as I can! |
@cnf any result? |
Using |
I made go-gorm/gorm.io#230 to update documentation here. |
My apologies, RL got in the way, have not had time to test this yet. |
Sadly, this didn't fully address my issues. After starting using shared cache, database locking and database table locking errors started to randomly popping up, breaking our tests randomly. I have to also call
I have also read that those lock issues might be happening if you are not closing rows using Moreover, I ended up using |
db, err := gorm.Open(sqlite.Open(":memory:"), &gorm.Config{}) assert.Nil(err, "open db error") // SetMaxOpenConns 1 |
Go Version: 1.13
Database: sqlite3
:memory:
Accessing a sqlite memory database concurrently gives strange results.
(no such table panic). This in only triggered when the db is accessed from multiple go routines simultaneous.
Using the lock does not panic
Using a non :memory: sqlite database does also NOT crash
The text was updated successfully, but these errors were encountered: