If you implement transactions with a mutex, you don't need roll-back, in normal use. A roll-back can occurs if multiple transactions run at the same time and one of them changes the input data of another one. I don't know other situations where a roll-back is necessary (despite for a "cancel" button that a user can press while transaction is still running). My server "Dedalo" fro the "Minosse" DB uses a simpler schema, with a Windows Critical Section for any command. That's works only for the nature of the application connected to Dedalo but can't be used for implementing transactions.Rémi Coulom wrote:Yes, I already have the consolidation operation. It is really very slow. But for my applications, it is not necessary, so I don't worry to much about this.
Transactions are not so difficult with a journal. I don't wish to implement transactions that can be rolled back. I don't think they are necessary, and they are too complicated to implement, whatever the data structure. I will only implement simple transactions that can only be commited. In the multi-user case, they will be like a mutex. So they will have to be short in time. This simplified form of transactions is very easy to implement, and should cover all practical needs. I only have to implement a "start transaction" and "end transaction" operation in the journal.
This kind of transaction is really required, for crash safety and multi-user access. Transactions that can be rolled back may be convenient, but I never used them, and their implementation is complex. I could do it by storing undo data in the journal, but it is too costly for my taste, and not useful in my practice.
I think to be a good-programmer but not a god-programmer... so I don't trust my DB enough for business application where hundreds thousands of euros has been involved, as condominium administration is. I use it with success in technical applications, somehow similar to spreadsheets, in fact.