Responses inline: 2008/5/27 Bryan Duxbury <[EMAIL PROTECTED]>: > It seems like if you wanted to do some manner of multi-row transactional > put, the only real way to manage it is with deletes. That is, if the first > put succeeds but the second fails, you can "invert" the first put into a > bunch of deletes.
Yes, this is what I was thinking by using the timestamp/multiple versions. To roll back you delete everything you wrote and then we get back to the previous version. Alternatively you could save the original values before they are overwritten. > Trying to make the regions themselves maintain the transactional state seems > like a terrible idea. You'd have to not allow a region to get migrated to > another server if it's serving a transaction. This would introduce a lot of > potential performance problems, I think. I'm envisioning transactions being relatively short-lived: 100 ms to a few seconds. I don't see this getting in the way of eg region migration any more than scanners do. But maybe I'm missing something. So the transactional state for a region is (roughly) a transaction lease, and a collection of the corresponding BatchUpdates. > Can you help me understand why atomic transactions are needed? Can't the > atomicity problems be sort of resolved by the whole row versioning thing? Simply, we need to ensure that all updates happen together. Otherwise, the data is in an inconsistent state. Take the standard example of debiting one account and crediting another. If only one of these rows gets updated, then the resulting table is corrupted and will not make sense to the application. (Money has been created or destroyed) So that is why one needs atomicity: the application-level semantics demand it. When we encounter an exception midway through the transaction, we can recover the old state of the modified row(s) by reverting to the previous version. So the question is who recognizes this and does the rollback? I'd like hbase to do it because it seems like a logical place to put the behavior. So if the client crashed halfway through the transaction, then when his transaction lease expires, hbase will revert the relevant BatchUpdates. And the integrity of our table is preserved! > Other databases that do transactions and rollbacks use versioning to > accomplish that, I think. I don't know much about this. But however other (R)DBMS implement it, it is provided as a primitive rather than implemented on top of underlying versioning functionality (by users). This way the database will maintain the consistency rather than the user having to recognize problems and revert the state itself. -clint
