Mutexes, locks, transactions -- they all may seem more relevant in compiled languages, lower level drivers or in databases; however, race conditions can be of equal dilemma in modern web applications. Something as simple as a user double clicking a submit form can yield unexpected results. These problems are difficult to replicate and to test, so they often go undetected. They can occur with or without significant traffic. Finally, with NoSQL alternatives growing in popularity for storing data and as caching layers, we need new alternatives to database transactions and locking. In this session, I will present situations which are vulnerable to race conditions, along with solutions. I'll also talk about locking approaches that are reliable, efficient and scalable.

1. Locking and Race Conditions in Web Applications By Andrew Kandels

2. What is a Race Condition? When the completion of one operation depends on the completion of another, which in turn depends on the first. The Olive Garden Example: The waiter brings one breadstick for each person and then one additional. Each person eats one bread stick, leaving one breadstick in the basket. No one takes the last breadstick in fear of being labeled a scrooge.

4. Can be difficult to replicate

5. Error logs tend to be misleading

7. Multiple Operations in one “Unit of Work” In a multi-threaded environment such as a web server, this is a candidate for a race condition: Thread #1 fetch() = empty Thread #2 fetch() = empty Thread #1 create() Thread #2 create() // Exception: duplicate key

8. The Solution Use a database transaction. Use a global lock or semaphore. Use the UNIQUE / PRIMARY keys in your application logic: Best for frequent writes (email table) Best for frequent reads (setting lookup table)

10. Orphaned rows

11. Faulty reporting

13. Predictable successes and failures

14. Failures should leave the data source unaltered

15. Can be nested hierarchically:Sign Up Billing System Create Login Data Warehouse

16. Example Code

18. Reads are never blocked

19. Atomic operations

21. Deadlocks

24. Insufficient isolation level

25. Lack of indexes

26. Locking queries:INSERT INTO table1 SELECT *FROM table 2;Note: SHOW INNODB STATUS is a great tool for debugging deadlocks.

28. Database Semaphore

29. Memcached

30. MongoDB

31. APC

33. Database Named Semaphore A semaphore is different than a transaction because the lock is independent of any single data source or operation.

34. Memcached Named Lock Memcached offers an additional advantage by natively providing a timeout.

36. Consider an ajax only web server

37. Read-only sessions by default

38. Variable isolation / separation

39. Increment caches with routine flushing

41. Memcached/MongoDB increment()

42. JavaScript to an analytics node (or GA)

43. Scheduled access log processing (e.g.: ETL)