Hi, Thomas Keller wrote:
If a revision, which is added to a monotone database, is recorded as several single inserts and/or other operations which itself run inside a transaction, you can't say for sure that a decomposition of this single transaction into several SQL commands, which are then recorded and applied backwards without any transaction mechanism will never somehow introduce database inconsistencies.
Hm, right. Concurrent readers could have read the data *before* it got reverted by some kind of a redo transaction.
Sure, this may not be a problem at all if the database you're applying the redo on is not used by a second process, but Zack proposed this for Ralf's NETSYNC use case AFAIR.
Yes, and AFAICT the whole purpose of multiplexing and splitting into different transactions is to allow some concurrency. If we disallow that, we could as well simply give each netsync session it's own transaction. And then again, we didn't have the redo problem, but could simply abort the complete transaction.
Regards Markus _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
