Hello,
is it possible to implement transaction behavior by dirty operations in mnesia ?
I have a situation where Iam using only dirty operations with “1 worker per key” (phash2) and everything is fine, but there are some cases where I have to write for example more than 1 record and atomicity should be guaranteed(all writes should be done or no one), I can’t find any way to ensure atomicity by logical code, so is there a solution except transactions ?
I ask that because there are some servers that don’t use transactions like whatsapp(that what was said in youtube conferences), and surely they had cases for atomic blocks of dirty operations so I think there is a way but I didn’t find it anyway.
is it possible to implement transaction behavior by dirty operations in mnesia ?
Only by implementing locks and requiring all involved parties to go through “your” transaction layer. It’s not rocket science, but it requires a lot of work to get it right.
If you need transactions with Mnesia, just use Mnesia’s transactions. Anything else is going to be painful.
I can’t comment on whatsapp.
2 Likes
Exactly a lot of coding, I didn’t use transactions because most of my logic don’t rely on it, I need transactions just in rare situations when I can’t anyway recover the damage from a sudden crash inside the atomic block…
But I think I found a solution, I will describe it maybe someone will be found in the same situation in the future: the issue was that I couldn’t mix dirty operations with transactions because dirty writes don’t respect anything and just write data immediately even if another process runs a transaction in parallel, so what I did is freezing all processes that participate in the atomic block from doing anything concerning the records in question after ensuring that they didn’t read data from those records because that will cause race conditions, for example if the atomic block has to write 3 records in 3 different tables then the 3 processes responsible for that should be locked from read/write to those records until the end of transaction, and also ensuring that no one of them have read record data before the transaction, because if so then it will write old data to the updated data(race conditions). The locking mechanism can be anything depending on your logic and your use cases, for example I have used the process state to ensure that. Thank you @mikpe