To prevent double posting, a snapshot will now consider the current transaction as 'in-progress'. A side effect of this is that the slaves may be one transaction behind the master during periods of low volume.
To fix the side effect, a 'GenerateSnapshotThread' has been added, which generates a snapshot once every configurable miliseconds (by default, 1000ms, or 1s). This snapshot is taken within a transaction with no other changes, so it does not matter that its transaction gets processed or not.
An interesting side effect of the side effect fix is this: There will always be a snapshot once every N miliseconds to process, and this should make replication lag to the slaves more predictable, and thus, more monitorable. Particularly so during periods of very low volume.
Some other minor changes included in this checkin:
* ReplicationDaemon names the GenerateSnapshotThread, so I made it name the LogSwitchThread too. * TidsBetweenSnapshotSet now has a meaningful toString() method.
Minor changes along the way: * Snapshot.tIDsBetweenSnapshots() no longer in use, and dropped * Drop mortal user remenents at the end of MortalUserCanModifyTableTest.