---

Determining Requirements

The first step in instrumenting multihreading in an Enterprise Objects application is determining if you really need to. Multithreaded applications of any type are inherently more difficult to program, debug, and maintain than those that use a single thread.

In the context of Enterprise Objects and WebObjects, it is usually better to allocate more application instances and more hardware on which to run those instances rather than to complicate your applications by instrumenting concurrency programmatically. Hardware today is rather cheap and sometimes using more servers is the most reasonable solution to service multiple concurrent users of the same database.

The second step in instrumenting multithreading in an Enterprise Objects application is determining what kind of concurrency you need. This requires knowing (or predicting) the bottlenecks within your application. Do bottlenecks occur at the database level when multiple users attempt concurrent access to the data source so that adding more database channels alleviates the bottleneck? Do bottlenecks occur elsewhere in the access layer so that providing a separate access layer for each user alleviates the bottleneck?

The answers to these questions help determine the mechanism you need to use to instrument concurrency within an Enterprise Objects application. Two common design patterns for concurrency within Enterprise Objects applications are to:

• Provide each user with an independent access layer stack.

• Provide multiple database channels on demand.

Both of these options provide concurrency within the access layer, which is usually sufficient to achieve multithreading within Enterprise Objects.

The first design pattern is discussed in “Providing Separate Stacks.” The second is discussed in “Database Channels.”

---