カン 545f5a3672 fix(database): prevent "database is locked" with WAL mode and single connection pool ... SQLite's default DELETE journal mode combined with an unbounded GORM connection pool allows multiple goroutines (XrayTrafficJob every 10s, PeriodicResetJob hourly/daily, WebSocket tickers) to each obtain their own connection and race for the write lock. When a long-running transaction holds the lock longer than go-sqlite3's busy_timeout the competing writer fails with "database is locked" (issue #3739). Two changes to InitDB: - Enable WAL journal mode (_journal_mode=WAL, _synchronous=NORMAL): readers no longer block writers, reducing the write-lock window. Restores the fix from PR #2645 that was accidentally reverted in the "revert group management" commit (d18a1a37). - SetMaxOpenConns(1): serialises all GORM access through a single connection at the Go pool level so SQLite write-lock contention cannot occur regardless of transaction duration. Add database/concurrent_test.go with two test functions: - TestConcurrentWrites: behavioural proof — reproduces the root cause (two connections + short busy_timeout → "database is locked"), then proves SetMaxOpenConns(1) eliminates it by serialising at pool level. - TestInitDBConcurrencyConfig: verifies InitDB applies both settings, completing the chain of proof that the production code path is fixed. Closes #3739 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>		2026-04-29 15:41:30 +09:00
..
model	hysteria: also accept "hysteria2" protocol string	2026-04-22 18:55:09 +03:00
concurrent_test.go	fix(database): prevent "database is locked" with WAL mode and single connection pool	2026-04-29 15:41:30 +09:00
db.go	fix(database): prevent "database is locked" with WAL mode and single connection pool	2026-04-29 15:41:30 +09:00