Question

I have read that PHPs “probable” weakness is how it handles “concurrency”. With only sessions and cookies to keep track of user state, how can PHP handle the following situations with high accuracy:

1. multiple users check out with one item that has only 1 stock in inventory (sorry for grammar mistakes, but you pretty much get the picture already)

2. multiple users logging into the same user account using the same login details

3. multiple users editing an the same image at the same time (though this rarely happens in real life)

or any other transactions that demands multiple thread handling

(I apologize if I misused terms here)

Answer 1

These aren’t real concurrency issues. While it’s true that PHP as an environment lacks in thread capability, any web server utilizing a PHP module will have multiple threads, each with thier own active PHP environment inside it, all utilizing the same resources. You would run into these problems with Java, .Net, Perl, or any other web application language.

1. You need a transaction on your database, probably with a write lock so that other users can’t read it and run the checkout process while someone else is checking out. This is not a language thread issue, it’s a database transactional issue.
2. This isn’t a threading issue either. Sessions are fairly trivial with all the tools available, and I’ve never heard of a “one thread per session” style of implementation on any language platform (that would be non-trivial, difficult to implement, and would just add overhead). You either allow multiple session tokens to be active for one account (user can log in multiple times on different tabs or web browsers if they want), or you don’t (all session tokens are cleared each time a login procedure occurs so that only one token is active).
3. An odd one, but I’m not sure how threading fits here either. Image editing would have to be done client-side in the browser. You can’t keep “threads” open to a user’s browser in any language… HTTP doesn’t work like that. You’d send them the image and you’re done until they hit “save” and send it back. If you’re worried about users overwriting each other’s changes, again, you’d just have to put a transactional lock on it. I’d probably just “version” each image, and if an update occurred from one user while another was editing it, you’d inform the other user that they needed to refresh their copy.

As far as I’m aware, no language uses threads to accomplish any of these tasks. Because of the stateless nature of HTTP communication, cookies are sessions are a mainstay of every web language, so no matter what platform you use, you’re going to see very much the same strategy in all of them for handling a given problem.