Netscape Internet Service Broker for Java: Programmer's Guide, Version 1.0

[Contents] [Previous] [Next]

Chapter 9
Managing Threads and Connections

This chapter discusses the use of threads and thread policy in client applications and object implementations. Java applications, by their very nature, support multiple threads and the ISB for Java core automatically uses threads for its internal processing, resulting in more efficient request management. All code within a server that implements an ORB object must be thread-safe. You must take special care when accessing a system-wide resource within an object implementation. For example, many database access methods are not thread-safe. Before your object implementation attempts to access such a resource, it must first lock access to the resource using a synchronized block.

Server Thread-per-session Policy

ISB for Java supports a thread-per-session policy for managing threads. With the thread-per-session policy, threading is driven by connections between the client and server processes. A new worker thread is allocated each time a client connects to a server. A worker thread is assigned to handle all the requests received from a particular client. When the client disconnects from the server, the worker thread is destroyed.

Figure 9.1 shows the use of the thread-per-session policy. The Client Application #1 establishes a connection with the object implementation. A separate connection exists between Client Application #2 and the object implementation. When a request comes in to the object implementation from Client Application #1, a worker thread handles the request. When a request from Client Application #2 comes in, a different worker thread is assigned to handle this request.

Figure 9.1    An object implementation using the thread-per-session policy

In Figure 9.2, a second request has come in to the object implementation from Client Application #1. The same worker thread that handles request 1 will handle request 2. When the worker thread completes request 1, then it can handle request 2 from Client Application #1--and any other future requests that come in after it finishes. Multiple requests can come in from Client Application #1--they are handled in the order that they come in; no additional worker threads are assigned to Client Application #1.

Figure 9.2    Thread-per-session: a second request comes in from the same client

If you want the worker thread to handle more than one request from the same Client Application simultaneously, you must call the Object._clone method. This creates a second connection from the Client Application to the Object Implementation and enables the Object Implementation to handle another request simultaneously. If the client uses the _clone operation, another connection is established. Because connections are a limited operating resource, it is important to limit the use of _clone operations.

[Contents] [Previous] [Next]

Last Updated: 02/04/98 13:48:00

Copyright © 1997 Netscape Communications Corporation

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use