|
|
|
|
|
|
How Multithreading and Multicontexting Work in a Client
When a multithreaded and multicontexted application is active, the life cycle of a client can be described in three phases:
In the start-up phase the following events occur:
Note: There may also be threads that work independently of the BEA Tuxedo system. We do not consider such threads in this documentation.
Client Threads Join Multiple Contexts
A client in a BEA Tuxedo multicontexted application can have more than one application association as long as the following rules are observed:
To join multiple contexts, clients call the tpinit() function with the TPMULTICONTEXTS flag set in the flags element of the TPINFO data type.
When tpinit() is called with the TPMULTICONTEXTS flag set, a new application association is created and is designated the current association for the thread. The BEA Tuxedo domain to which the new association is made is determined by the value of the TUXCONFIG or WSENVFILE/WSNADDR environment variable.
Client Threads Switch to an Existing Context
Many ATMI functions operate on a per-context basis. (For a complete list, see Using Per-context Functions and Data Structures in a Multithreaded Client.) In such cases, the target context must be the current context. Although clients can join more than one context, at any time, in any thread, only one context can be the current context.
As task priorities shift within an application, requiring interactions with one BEA Tuxedo domain rather than another, it is sometimes advantageous to re-assign a thread from one context to another.
In such situations, one client threads calls tpgetctxt(3c) and passes the handle that is returned (the value of which is the current context) to a second client thread. The second thread then associates itself with the current context by calling tpsetctxt(3c) and specifying the handle it received from tpgetctxt(3c) via the first thread.
Once the second thread is associated with the desired context, it is available to perform tasks executed by ATMI functions that operate on a per-context basis. For details, see Using Per-context Functions and Data Structures in a Multithreaded Client.
Work Phase
In this phase each thread performs a task. The following is a list of sample tasks:
A thread sends a request to a server by calling either tpcall() for a synchronous request or tpacall() for an asynchronous request. If the request is sent with tpcall(), then the reply is received without further action by any thread.
Replies to Service Requests
If an asynchronous request for a service has been sent with tpcall(), a thread in the same context (which may or may not be the same thread that sent the request) gets the reply by calling tpgetrply().
Transactions
If one thread starts a transaction, then all threads that share the context of that thread also share the transaction.
Many threads in a context may work on a transaction, but only one thread may commit or abort it. The thread that commits or aborts the transaction can be any thread working on the transaction; it is not necessarily the same thread that started the transaction. Threaded applications are responsible for providing appropriate synchronization so that the normal rules of transactions are followed. (For example, there can be no outstanding RPC calls or conversations when a transaction is committed, and no stray calls are allowed after a transaction has been committed or aborted.) A process may be part of at most one transaction for each of its application associations.
If one thread of an application calls tpcommit() concurrently with an RPC or conversational call in another thread of the application, the system acts as if the calls were issued in some serial order. An application context may temporarily suspend work on a transaction by calling tpsuspend() and then start another transaction subject to the same restrictions that exist for single-threaded and single-context programs.
Unsolicited Messages
For each context in a multithreaded or multicontexted application, you may choose one of three methods for handling unsolicited messages.
|
A context may . . . |
By setting . . . |
|---|---|
|
Ignore unsolicited messages |
TPU_IGN |
|
Use dip-in notification |
TPU_DIP |
|
Use dedicated thread notification. |
TPU_THREAD |
The following caveats apply:
If receiving immediate notification of events is important to your application, then you should carefully consider whether to use a multicontexted approach on this platform.
When dedicated thread notification is chosen, the system dedicates a separate thread to receive unsolicited messages and dispatch the unsolicited message handler. Only one copy of the unsolicited message handler can run at any one time in a given context.
If tpinit() is called on a platform for which the BEA Tuxedo system does not support threads, with parameters indicating that TPU_THREAD notification is being requested on a platform that does not support threads, tpinit() returns -1 and sets tperrno to TPEINVAL. If the UBBCONFIG(5) default NOTIFY option is set to THREAD but threads are not available on a particular machine, the default behavior for that machine is downgraded to DIPIN. The difference between these two behaviors allows an administrator to specify a default for all machines in a mixed configuration-a configuration that includes some machines that support threads and some that do not-but it does not allow a client to explicitly request a behavior that is not available on its machine.
If tpsetunsol() is called from a thread that is not associated with a context, a per-process default unsolicited message handler for all new tpinit() contexts created is established. A specific context may change the unsolicited message handler for that context by calling tpsetunsol() again when the context is active. The per-process default unsolicited message handler may be changed by again calling tpsetunsol() in a thread not currently associated with a context.
If a process has multiple associations with the same application, then each association is assigned a different CLIENTID so that it is possible to send an unsolicited message to a specific application association. If a process has multiple associations with the same application, then any tpbroadcast() is sent separately to each of the application associations that meet the broadcast criteria. When performing a dip-in check for receiving unsolicited messages, an application checks for only those messages sent to the current application association.
In addition to the ATMI functions permitted in unsolicited message handlers, it is permissible to call tpgetctxt(3c) within an unsolicited message handler. This functionality allows an unsolicited message handler to create another thread to perform any more substantial ATMI work required within the same context.
Userlog Maintains Thread-specific Information
For each thread in each application, userlog(3c) records the following identifying information:
process_ID.thread_ID.context_ID
Placeholders are printed in the thread_ID and context_ID fields of entries for non-threaded platforms and single-contexted applications.
The TM_MIB(5) supports this functionality in the TA_THREADID and TA_CONTEXTID fields in the T_ULOG class.
Completion Phase
In this phase, when the client process is about to exit, on behalf of the current context and all associated threads, a thread ends its application association by calling tpterm(). Like other ATMI functions, tpterm() operates on the current context. It affects all threads for which the context is set to the terminated context, and terminates any commonality of context among these threads.
A well-designed application normally waits for all work in a particular context to complete before it calls tpterm(). Be sure that all threads are synchronized before your application calls tpterm().
See Also
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|