Alex Jbanca 790efc16aa fix(databaseLocks): Fixing database lock errors on transactions
The default transaction lock is `deferred`. This means that the transaction will automatically become read or write transaction based on the first DB operation. In case the first operation is `SELECT` the transaction becomes read transaction, otherwise write transaction. When a read transaction tries to write the DB sqlite will promote the transaction to a write transaction if there is no other transaction that holds a lock. When the promotion fails `database is locked` error is returned. The error is returned immediately and does not use the busy handler.
In our case almost all read transaction would fail with `database is locked` error.

This fix is changing the default transaction lock to `IMMEDIATE`. It translates to `BEGIN IMMEDIATE` instead of `BEGIN`. In this mode, the transaction will be created as a write transaction no matter what DB operation will run as part of the transaction. The write transaction will try to obtain the DB lock immediately when `BEGIN IMMEDIATE` is called and the busy handler is used when the DB is locked by other transaction.

Fixing: https://github.com/status-im/status-desktop/issues/10838
2023-05-31 08:46:26 +02:00
2021-06-16 16:19:45 -04:00
2022-11-17 10:40:26 +01:00
2023-01-13 17:52:03 +00:00
2023-05-30 23:09:36 +02:00
2021-07-20 10:57:38 +02:00
2022-03-28 13:14:12 +01:00
2022-03-28 13:14:12 +01:00
2021-07-20 10:57:38 +02:00
2023-01-13 17:52:03 +00:00
2023-05-24 18:48:16 +03:00
2022-12-29 14:16:19 +08:00
2021-09-01 13:02:18 +01:00
2023-05-24 18:48:16 +03:00
2022-07-17 15:37:14 +02:00
2021-07-20 10:57:38 +02:00
2023-05-30 10:49:52 -04:00
2023-01-13 17:52:03 +00:00
2023-05-30 10:49:52 -04:00
2023-05-30 10:49:52 -04:00
2016-09-21 10:00:29 +08:00
2023-05-24 18:48:16 +03:00
Description
The Status module that consumes go-ethereum
https://status.im
Readme
Languages
Go 98.5%
Python 0.9%
Shell 0.3%
Makefile 0.1%
Groovy 0.1%