Would write-ahead logging (from database transactions) work for transactional memory, but be prehibitively slow / unnecessary? I see Lazy versioning as a decent parallel to write-ahead logs, but not sure distinct differences other than the log being permanent in databases.

@swkonz Database transactions get committed to disk, with memory being the work space. Here we want transactions to remain in memory, so I think a WAL would end up being the same as a write-buffer.

Some file systems do use a version of WAL (called journaling) for metadata.

@potato I'm not sure if I agree with you that WAL more closely resembles lazy data versioning using a write buffer. If I recall correctly, WAL involves writing undo information to some sort of log file so that the database can restore itself to a clean state if there was some sort of sudden and catastrophic failure. In this sense, I feel as if it's more closely resembles eager data versioning, because of the generation of undo data. However, I agree with you that eager versioning isn't exactly WAL either.

Are there examples of different systems that use each type of data versioning? I've seen most databases use lazy loading in that they kind of "get to writing when they can", but I don't recall having ever seen an example of eager loading.