Do we also have to write metadata to indicate that some address in memory is not valid until transaction has committed?

I'm wondering if undo-log should be durable or recoverable if there is a crash of the machine (so all content in the memory are lost)?

@minglotus I'm wondering whether to what extent this is possible - it seems very, very expensive to write the undo log to storage on every update!

Can the undo log be written to storage asynchronously?

How do we ensure isolation with eager versioning if memory have been updated before transaction commits?

@xiyan -- because eager versioning is paired with pessimistic detection. Implementations will check for conflicts before reading the data from memory.

@minglotus I'm not sure we even need to have a durable undo log in the case for regular transactional memory. I know durability is a requirement for ACID (Atomic / Consistent / Independent / Durable) transactions in databases, but I think a big thing to note here is that we're nly working within a single system. If it happens that the computer crashes, the memory is lost, and we simply have to run the program again at some point.

In other words, I don't think there's anything "wrong" with just letting the computer crash in the middle of a transaction (from the perspective of atomicity). As @superscalar said, writing to files is an order of magnitude slower than writing to memory, especially since the OS needs to keep track of several file-related structures and update them appropriately.

To give concrete numbers, the latency to write a block (512 bytes / determined by the disk) is 13ms. The time it takes to write to memory is around 100ns for a good DR memory (https://stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory) . This means that we'd be slowing down by a factor of over 1000x! I think this proof of concept makes it clear that for a fast and efficient transactional memory, we may need to give up durability.