With processing loads constantly increasing, the conventional way of addressing the issue is to add more servers with the same .ear or .war file deployed and then join them all together in a cluster. This way, a failed server can be automatically replaced with another one, and the system will experience no decrease in its performance. The database that backs all the clustered servers is typically clustered too.
Increasing the number of clustered servers, however, is far too coarse-grained a solution for scalability, especially if the processing bottleneck is localized in only one of many procedures that are running in the application. Imagine that one particular CPU- or I/O-intensive process slows down the whole application; adding another server just to mitigate the problem of only one part of the application may carry too much of an overhead.
One...