Race conditions in applications can be one of the hardest things to work out the kinks on, especially in a more complex application you're adding the new functionality to. One such instance comes up when you add Ajax functionality into the mix. Because of its asynchronous nature, it can cause a race condition version easily.
Andy Bakun has been there and done that in his code and has found some helpful hints he's sharing in
this (info packed) post over on his blog.
One of the problem with race conditions is that it is often difficult to actually witness the ramifications of one when it happens, especially if you are not aware of it. If you've used PHP's built-in, default session handling (that uses files), you'll never come across the problem. However, things get interesting once you start using session_set_save_handler to write your own session handler.
He
breaks it down into some more manageable chunks:
- A Multi-processing but non-Threaded Environment
- The Default PHP Session Handler
- Observing the Race Condition
- The Demo App Interface
- Resource Contention
- Minimizing Lock Holding Time
- Why is per-variable locking important?
- Rolling Your Own Session HandlerThe Code
See? You didn't believe me when I said it was long...there's tons of great info in there about working with sessions in PHP and how to get Ajax to play nice when manipulating the data inside them. There's plenty of test code and some sidebars with additional information to keep you reading for a while. Be sure to check this one out, even if you're just working with PHP sessions and Ajax and don't have a race condition issue in your app - never hurts to be prepared.
Andy Bakun's Blog: Race Conditions with Ajax and PHP Sessions - Read More...
