so I've been thinking a bit more about everything...
transaction locks could be kind of hacked on by having a "Lock" element in each tuple that represents the row of a table... that element would contain the Pid of the process thats holding the lock executing the current transaction (and that was spawned by the transaction manager)(or the Pid would be stored someplace else for efficiency reasons, the point is that there's a Pid per row). If another transaction wanted to write/read from a locked row the transaction manager would just not execute it, and leave it in the queue for later attempts (next time it tail recurses). I would have to think more about how Checkpoints would work as well... but overall Im starting to understand how things are structured, at least conceptually... its gonna be ugly ;)) and probably orders of magnitude slower than what Mnesia pulls off, but at least I'll learn plenty...
about distributed transactions... Im guessing that the transaction fun is sent over the wire to another node by converting it into a binary first and then reconstructing it on the other end... now, a question about that. Since the fun is a closure, say that Im using a variable in the fun thats bound outside the fun, with say a list of 10 elements, and then the the closure is passed in as a transaction that is to be executed on another node (transparently by the transaction manager) - Im assuming for the closure semantics to stand that the list with 10 elements would be sent as well as a part of the lexical environment that the closure "closes" over... am I missing something here? just thinking about how would one implemented distributed transactions...
thanks