does it mean, copy on write, regardless of whether the same key is being read by another read only transaction¹. is this why readers and writers don't block each other?
a transaction is also needed for reading only. a transaction provide a consistent view of the data
meaning, whenever we view a key from lmdb under an executing transaction, we have the guarantee that it will not change until we are done with it, ie, until we release the transaction handle.
now given²
writers cannot block readers, and readers don't block writers
and lmdb using copy on write³
and release that transaction because what if a trnsaction is viewing some memory and another write transaction is finished modying that same region in the meanwhile
what happens? so if writers are not blocked by readers, the modification would be committed into memory. in to the database. so even though same area was intended for modification, the copy on write strategy made a copy of it, and freely made changes into it and left the changes at a new address. would the readonly transaction still have the old view of the data? would any new read only transactions instantiated after the write was committed have the view to the latest data, while one of their older cousins is still having an old view of the data? which would be lost if this txn released it. because then all new txns would view only the latest data. so in essence, isn't this old painting on the same region, lost forever?
¹ read only because, writes transactions are anyway fully serialised, so if there's any other write transaction wanting to write to the same key, it will be queued up, somewhere after the currently undergoing transaction.
lmdb uses copy on write stategy
does it mean, copy on write, regardless of whether the same key is being read by another read only transaction¹. is this why readers and writers don't block each other?
a transaction is also needed for reading only. a transaction provide a consistent view of the data
meaning, whenever we view a key from lmdb under an executing transaction, we have the guarantee that it will not change until we are done with it, ie, until we release the transaction handle.
now given²
and lmdb using copy on write³
and release that transaction because what if a trnsaction is viewing some memory and another write transaction is finished modying that same region in the meanwhile what happens? so if writers are not blocked by readers, the modification would be committed into memory. in to the database. so even though same area was intended for modification, the copy on write strategy made a copy of it, and freely made changes into it and left the changes at a new address. would the readonly transaction still have the old view of the data? would any new read only transactions instantiated after the write was committed have the view to the latest data, while one of their older cousins is still having an old view of the data? which would be lost if this txn released it. because then all new txns would view only the latest data. so in essence, isn't this old painting on the same region, lost forever?
¹ read only because, writes transactions are anyway fully serialised, so if there's any other write transaction wanting to write to the same key, it will be queued up, somewhere after the currently undergoing transaction.
² ³