Hi,
A connection doesn't need to check locks on every statement -
only when it tries to spill to disk, most commonly during
commit.
I think I understand what you wrote.
So the bit of my program can think that its changes were
written to the database and only later might my program find
that they weren't ? By which time it might no longer know what
they were ?
Should I have used BEGIN EXCLUSIVE ?
The part of your program that performs the transaction and associated
business logic should be repeatable. That is, you should be able to call it
one or more times without side effects. After it succeeds you can perform
any side effects you require.
If I don't have time to engineer all the business logic in a functional
style I try to do all the reads in the first part of the transaction and
then all the writes in the second part. I then store all the writes in a
list and, if the transaction fails, I can retry just the statements in the
list. This has several caveats:
This assumes that the transaction does eventually succeed and that the
writes are not dependent on the reads whose data might have been modified
by other transactions. You can sometimes arrange for this property with
careful design of the database schema but unless you're very careful you
can end up corrupting the business state in the database in a way that is
difficult or impossible to detect or debug. It works best (i.e. most
safely) with plain INSERTs. i.e. when you don't overwrite any of the
existing data with UPDATE or UPSERT-style statements.
If this is too much trouble then you can, as you say, use BEGIN EXCLUSIVE
and fix it when you get to the point where more concurrency is required.
Best wishes,
@ndy
--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
