As for (1), SQL database and CDB have their own mechanism to serialize the concurrent access, so we will not worry about it.
Well SQL has its own locking, be it table or row level that will prevent a single domain from being updated at the same time.  For example, an update and a delete will either update and then delete, or delete and then fail on an update.  Either way, it does the right thing.
As for (2), there may be a chance of conflict in theory, because vpop
commands do not implement the mechanism to avoid the concurrent access.
But, in the real world, it is the rare case that the same folder is
created/deleted at the same time.
When would you create a user and delete them at the exact same time?  Either the user exists or doesn't.  Whatever state you end up in is probably sane, and odds are you won't do multiple actions as each depend on the opposite state.
So, we need not to worry about the concurrent usage of vpop commands.
Is my understanding correct?
A big question is what harm can you cause?  Concurrency can always lead to unpredictability, unless you lock the whole process.  Even then, you could issue a command that negates the command before it (as a whole).  Worst case updating a password for an e-mail address fails because the e-mail address is deleted... so it probably doesn't matter what the password is.  Worst case you are updating a domain and it gets deleted, so again, who cares about the update- and occurring in the other order is fine too.

Vpopmail will prevent corruption of your data, by using locking if needed (or depend on locking of a DB system).  It will lock .qmail files when it writes them.  Everything else shouldn't really matter.  Maildir if it doesn't exist will be created, but you shouldn't get to that state.

In a database, concurrency has issues.  The textbook example is subtracting from an account balance, where if two programs update the balance at the same time (through two transactions), then they can cause problems (currbal=100, currbal-50, currbal-10 -=- possible outcomes are 90, 50, or 40).  In this case, multiple updates to the same datum are uncommon, and any irregularity is still something the user wanted.


Reply via email to