bug#32234: [PATCH 2/2] database: Serialize all database accesses in a thread.

[Clément Lassieur]

Hi Danny,

Danny Milosavljevic <address@hidden> writes:

> Hi Clément,
>
> in the future I plan on making the actual bin/evaluate use another database 
> connection
> in order for the web interface to be isolated while it's querying.

I don't understand... bin/evaluate doesn't query the database at all.  I
don't know why it would need to.

> Otherwise - as it is now in master - it can happen that while you are 
> querying one
> page, half of the things have different values than you requested - which is 
> really
> weird.
>
> For example right now you could query for a row with status=42 and get back 
> data with
> status=43 (because it has been changed in the mean time).

Could you please show an example that I can reproduce?  I don't
understand what you mean.

> It's better to have serializable transaction isolation to prevent this.  That 
> means
> that each connection will have its own worldview that is fixed at the 
> beginning of
> the connection's transaction.  The worldview will update only once a new 
> transaction
> starts.

With that patch, database queries are serialized, which means that if
query1, query2 and query3 are sent in that order, they will be executed
in that order, one after the other.  I don't understand why using a
different connection would improve things.

> Therefore, it would be good for writers to have their own connection in the 
> long run
> (really, for the readers to have their own connection - but that comes out 
> the same).

Currently, there is only one connection that is shared by the writers
and readers.  Having one 'read connection' and one 'write connection'
would be possible and make sense if both of them live in a separate
thread and use the SQLite multithreading feature so that writing and
reading proceed concurrently.  Is that what you mean?

Clément