Michael Conrad wrote:
On 07/10/2017 03:28 PM, Howard Chu wrote:Michael Conrad wrote:On 07/10/2017 12:16 PM, Howard Chu wrote:Michael Conrad wrote:Hi, I'm scoping out my options for databases that support snapshotting. From what I've read so far, this is a natural feature of LMDB,Not really. The persistent state only records the 2 most recent transactions.Hm, well so much for that idea ;-) But could you clarify what would happen in a scenario like:Proc1: Begin Read Transaction t1 Proc2: Write Transaction t2 Proc2: Write transaction t3 Proc3: Begin Read Transaction t4 Proc2: Write Transaction t5 Proc2: Write Transaction t6After those steps, are process 1 and process 3 still able to continue reading their data, and is all the data they see consistent with the state of the database at the time they began the transaction?Yes. They each retain an in-memory copy of the DB metadata at the start of their transaction, and none of the pages they require can be reused by any write transactions.So, if I found a way to serialize the metadata being held by the transaction, and maintain the lock on the pages, then in theory I could re-load the transaction later to see the historic state?
You would need to keep process 1 and process 3 alive, to maintain their locks.
And the downside to attempting this would be that (assuming an idle database at the start of the read transaction) *no* pages would get garbage collected at all for a long as the lock was held?
Correct. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/