Some questions about the transaction support

[yahaoohoo]

Hi,

KVell is an excellent work. I'm very interested in it. I'm very curious about the transaction support. How does KVell support atomicity and isolation? Are "share nothing" and "partition" designs still efficient in the transaction support?

1. If there are multiple updates in one transaction, they can be mapped to different workers and written to different devices. How does KVell guarantee none or all of them are persistent to devices ? If the system crash during a transaction processing and only part of the updates are persistent to the devices, how to deal with this during recovery?

2. If there are two concurrent transactions, how to guarantee that Txn A can not see Txn B's uncommitted updates? Which isolation level does it support (read uncommitted, read committed or repeatable read)?

3. In the paper, I found that YCSB-A (50% update and 50% read) always have the same performance with YCSB-F(50% update and 50% read-modify-write). Why do they always have the similar performance and how did KVell implement the read-modify-write?

Thanks.

[BLepers]

Thanks for your interest.

1&2. There is no transaction support in this version of KVell. We'll hopefully release a transactional version at some point.

3. In this prototype, we write in place. We read a page, modify the slot of a tuple, and then write. So it is not possible to "just update" without reading first. So update = read-modify-update always.

Cheers,