2013-05-15
| ||
18:21 | • Fixed ticket [e636a050]: Database corruption in shared cache mode plus 5 other changes (artifact: 79a6dca6 user: drh) | |
17:08 | Make sure an sqlite3_close() or a rollback on one shared-cache connection does not disrupt the operation of other connections using the same shared cache. Fix for ticket [e636a050b709]. (check-in: 5cc1cc55 user: drh tags: trunk) | |
10:21 | When closing a connection, avoid tripping active cursors belonging to a different shared-cache client. Also, if sqlite3_close() is called while there are still active statements belonging to the connection, return SQLITE_BUSY and do not roll back any active transaction. Proposed fix for ticket [e636a050b709]. (check-in: 6071b7cc user: dan tags: shared-cache-fixes) | |
2013-05-13
| ||
18:00 | • New ticket [e636a050] Database corruption in shared cache mode. (artifact: 2f2df1f3 user: drh) | |
Ticket Hash: | e636a050b709785c50ad14d6062267b6e1605b54 | |||
Title: | Database corruption in shared cache mode | |||
Status: | Fixed | Type: | Code_Defect | |
Severity: | Critical | Priority: | Immediate | |
Subsystem: | Unknown | Resolution: | Fixed | |
Last Modified: | 2013-05-15 18:21:44 | |||
Version Found In: | 3.7.16.2 | |||
User Comments: | ||||
drh added on 2013-05-13 18:00:00:
When two database connections share the same cache and one connection is in the middle of a write transaction and the other connection closes (with sqlite3_close) or rolls back a transaction on a different attached database, and the first connection continues to make changes to the database file and then commits, the first connection can cause the database file to go corrupt. |