Hi,
Thomas Keller wrote:
http://www.sqlite.org/cvstrac/wiki?p=UndoRedo might be a good starting point.
Doesn't this violate the ACID properties of a normal transaction
Uh huh? The above link describes a temporary table "holding the
information needed to undo/redo changes to the database". That certainly
does not pose any problems regarding ACID properties.
I'm somewhat concerned about the doubled throughput to disk. As with a
growing amount of revisions in the database, the disk quickly becomes
the bottleneck during netsync. (Not quite sure, subjective impression,
not hard measure).
I'm thinking of the transaction multiplexing as a kind of a hack around
sqlite's lack of fine grained locking (which would allow multiple
concurrent transactions). Instead of adding yet another hack (manual
redo log, sort of) I'd rather add support for a real RDBMS [1]. For the
server side part of the netsync story, that would make things simpler
and faster.
BTW: is netsync protocol documented somewhere? If not, I'm happy to
create such a document, as I'm trying to figure out the details anyway.
Regards
Markus
[1]: Whenever I'm saying this I'm clearly referring to Postgres :-)
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
