What are your locking requirements? Do you need some kind of transaction thing? (read from here, write here, write here, if no error commit, else fail and report error type stuff) or do you need to have the last changed record written by the tenth person? (1 writes, 2 writes, etc... 10 writes, all changes by 1 through 9 gone) or do you need it to append each "change" onto the end of the data stream, i.e. the outputs from 1 to 10 are saved as "patches" against the original, so that only the parts each changed are checked in? Have it error out for all users after number 1 saying your changes are too old, i.e. there's been a commit since you started. Are each of the pieces the folks would add to the article a tiny little universe unto itself in grammar and composition, or do they interact with the other parts.
Each of these examples involves locking the table/row/record/database/something, but each handles the dataflow coming back differently.
You gotta model your data flow, then build a simple test bed to see how many simo users you can handle with a given database and see if that gives you enough headroom to head into production. That's the first hald fo the problem. Abstract your db access so you can move easily if needed and you've got the second half of the problem solved too.
