-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paolo Vernazza wrote:
| But doing in that way, you can have this behaviour (and this is what | happends to me): | | db1: BEGIN TRANSACTION; -> SQLITE_OK | db2: BEGIN TRANSACTION; -> SQLITE_OK | | db1: INSERT INTO test VALUES ( 1 ); -> SQLITE_BUSY | db2: INSERT INTO test VALUES ( 1 ); -> SQLITE_BUSY | | db1: -> ROLLBACK -> SQLITE_OK | db2: -> ROLLBACK -> SQLITE_OK | | and then again.... | | db1: BEGIN TRANSACTION; -> SQLITE_OK | db2: BEGIN TRANSACTION; -> SQLITE_OK | | db1: INSERT INTO test VALUES ( 1 ); -> SQLITE_BUSY | db2: INSERT INTO test VALUES ( 1 ); -> SQLITE_BUSY | | db1: -> ROLLBACK -> SQLITE_OK | db2: -> ROLLBACK -> SQLITE_OK
Maybe a solution would be something like this:
All open transactions should have the same chance to commit. The first transaction that commits, will win. After a transaction won, all other transaction should return BUSY.
This will result to the following:
case a.)
db1: BEGIN TRANSACTION; -> SQLITE_OK db2: BEGIN TRANSACTION; -> SQLITE_OK
db1: INSERT ...; -> SQLITE_OK db2: INSERT ...; -> SQLITE_OK
db1: COMMIT; -> SQLITE_OK db2: COMMIT; -> SQLITE_BUSY
case b.)
db1: BEGIN TRANSACTION; -> SQLITE_OK db2: BEGIN TRANSACTION; -> SQLITE_OK
db2: INSERT ...; -> SQLITE_OK db2: COMMIT; -> SQLITE_OK
db1: INSERT ...; -> SQLITE_BUSY db1: ROLLBACK; -> SQLITE_OK
case c.)
db1: BEGIN TRANSACTION; -> SQLITE_OK db2: BEGIN TRANSACTION; -> SQLITE_OK
db2: INSERT ...; -> SQLITE_OK db1: INSERT ...; -> SQLITE_OK
db1: ROLLBACK; -> SQLITE_OK db2: COMMIT; -> SQLITE_OK
case d.)
db1: BEGIN TRANSACTION; -> SQLITE_OK db2: BEGIN TRANSACTION; -> SQLITE_OK
db1: SELECT ...; -> SQLITE_OK db2: INSERT ...; -> SQLITE_OK
db2: COMMIT; -> SQLITE_OK db1: COMMIT; -> SQLITE_OK
-----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGognSIrOxc3jOmoRAkm1AJ9NJb5GHanjL2kMCtVK4Wu7V7df6ACaA+IE k6UiJvLi5U18REV6zTaXegs= =vfJu -----END PGP SIGNATURE-----
