-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Michael Roth wrote:
| 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.
I thought a little bit more about it, and found that the above poliy is unfair when you have long running transactions and short running transactions and maybe won't fit very well to the sqlite3 pager.
The policy maybe could be:
All transactions start always. A transaction which first wrote to the database, will always win when it commits. After a transaction is selected to win, all other open transactions always returns BUSY, no matter if they execute a select or an update/insert, but this isn't true for the first statement in an transaction. The first statement in a transaction, no matter if it is a select or an update/insert, will call the busy handler if there is currently an other transaction that will win, i.e. an other transaction wrote already to the database. Only when the transaction selected to win commits or rollback, new transactions continue, if they don't time out in the busy handler.
Some errors in my idea?
-----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBGo8XSIrOxc3jOmoRAlFMAJ43qJRHdpM7J2C7Y97YW8rkH26mKwCfQ1fN GMCO8ueu/nzpcmnG7O5oIhg= =GCo1 -----END PGP SIGNATURE-----
