When a developer creates an application, a good deal of the design goes into defining what the capacities of the application are. How many records can the system hold? How many users can use the system at one time? How long will it take to retrieve a piece of data from the system? These are all questions about scalability. In other words, how well does the application grow? In a traditional application, it is up to the developer to provide answers to these questions when the system is being built. If the developer fails to address them, or does not address them properly, then the application will fail to scale. When this happens, as more users begin to access the system, and place a greater load on the system, things begin to fail. The system starts to buckle under the load of more users than it was designed for.
When working in a transaction-processing environment, those questions are answered for the developers without having to even think about them. The developer creates components that interact with the system as if they had exclusive access to the system, and had the full resources of the system available to it. The environment is responsible for efficiently managing the resources of the multiple objects that could be active at one time so that each one runs successfully. The environment can do things such as reusing objects, rather than creating new ones when they are needed and destroying them as their work is completed. By managing the lifetime of objects, the environment can ensure that as more and more objects are needed, which happens when more users are accessing the system, the system will be able to support them.