For SQLite-based games, we use read-transactions/snapshots of the database to decouple state reads from each other (i.e. when a request for state, such as RPC on the GSP, is made, a snapshot is created while the database is locked, but the actual processing of the data is done with the lock released again). While a block is being processed and the state updated, though, the process is globally locked, so state reads will have to wait until processing is finished.
We could pro-actively create a snapshot after each database update, and use that one to service state reads until the next update has finished. This would allow processing state reads (based on the previous consistent state) also in parallel to state updates.
For SQLite-based games, we use read-transactions/snapshots of the database to decouple state reads from each other (i.e. when a request for state, such as RPC on the GSP, is made, a snapshot is created while the database is locked, but the actual processing of the data is done with the lock released again). While a block is being processed and the state updated, though, the process is globally locked, so state reads will have to wait until processing is finished.
We could pro-actively create a snapshot after each database update, and use that one to service state reads until the next update has finished. This would allow processing state reads (based on the previous consistent state) also in parallel to state updates.