Most JS/Python/Ruby apps…
In a single-user application, the user can modify data without concern for other users modifying the same data at the same time. However, in a multi-user (or multi-thread) application, the statements within multiple simultaneous transactions can update the same data. Transactions executing at the same time need to produce meaningful and consistent results.
Therefore, a multi-user (thread) application must provide data consistency, which ensures that each user sees a consistent view of the data, including visible changes made by the user's own transactions and committed transactions of other users. In this way, the database can present a view of data to multiple concurrent users, with each view consistent to a point in time. Because different versions of data can exist simultaneously, transactions can read the version of data committed at the point in time required by a query and return results that are consistent to a single point in time. See Transactions - Concurrent Read Consistency (multiversion read)
Application that inhibit concurrency :
- are less scalable,
- can support fewer users
- and require more resources (or power)
To describe transaction behavior when transactions run concurrently, a transaction isolation model was defined.
If several transactions concurrently read from and write to a database, the following data problems can arise:
- Lost Update Problem
To avoid these problems, the only isolation level is the serializable one.
Computer users take it for granted that their systems can do more than one thing at a time. They assume that they can continue to work in a word processor, while other applications download files, manage the print queue, and stream audio.
Even a single application is often expected to do more than one thing at a time.
For example, that streaming audio application must simultaneously read the digital audio off the network, decompress it, manage playback, and update its display.
Even the word processor should always be ready to respond to keyboard and mouse events, no matter how busy it is reformatting text or updating the display.
Software that can do such things is known as concurrent software.
It's an area that sets a database apart from a file system and databases apart from each other.
If you don't have a good grasp of how your application implements concurrency control mechanisms, then you will :
- Corrupt the integrity of your data
Something that works in isolation will not work as you expect in a multi-user situation
- Have application run slower than they should with a small number of users
It will end up waiting for resources
- Decrease your ability to scale to a large number of users
On the system and application levels, concurrency is limited by sessions and socket connections. Code flaws and incorrect server configuration settings can also limit concurrency. Concurrency tests involve ramping up a number of users on the system and using realistic page-delay times at a ramp-up speed slow enough to gather useful data throughout the testing at each level of load. As with throughput testing, it is important to test the key pages and user transactions in the application under test.