General developer forum

Hi Marcus,

Thanks for the diagram ;)

Can you pls share the workbench version ?

No hell way to get it done with my machine and ressources :/

I am fairly familiar with concurrency issues (for example, I have written multi-threaded Java code in the past). I agree that it seems crazy that Moodle can work without transactions, etc. But it does seem to be a complete non-issue.

There are loads of bugs reported to the tracker, and I don't recall seeing one that is related to the lack of transactions. If there are things you want to worry about in the Moodle codebase, there are more important issues than this.


I suppose that even on a busy site ... well to continue with the OU example. So, we have about 5 requests per second, but actually those are spread (somewhat unevenly) over about 500 active courses, which suddenly takes the concurrency estimate way down again. On top of the point you make that there will be a lot of reads.


The worst-case scenario is probably when you have a whole class doing some interactive activity together. But if you want to do a back-of-the envelope calculation about what might go wrong, you start thinking about the nature of the activities.

Quiz, assignment, choice, glossary, ... each student's contributions are more-or-less independent of each other.

Something like forum, well students are only adding posts to a thread. You can only really get an issue if a moderator deletes a post at the same moment a user tries to post a reply, and seemingly the probability of that is vanishingly small.

Chat, again, is all inserts, and probably only inserts into a single table, so actually the key bit of that will be atomic.

I don't like to think what would happen if a student opened their quiz in IE and Firefox, and clicked Submit all and Finish in both in quick succession - but students don't tend to do that. (Also, I am currently rewriting the quiz, and the new version will have transactions.)

Also, if two teachers were editing the same course simultaneously, and moving activities, that might be bad, but it does not seem to happen in the real works.


Actually, one place I know where you get problems is restoring a backup (which you often do to copy a course). If you get an error half-way through a restore, then you get a lot of garbage in the database. So, I know that at the OU we wrapped the restore code in a transaction. And most of the OU custom code does use transactions, because we can, and obviously, if you know how, you just write code like that.

But anyway, whatever your previous experience tells you, I don't think you need to worry about the lack of transactions in Moodle.

A 30,000 ft view of locking:
MySQL uses table, read/write level locking to manage concurrency (among several other locking mechanisms). The table level locking prevents starvation and helps hold integrity.

http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html