Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	http://www.oracle.com/technology/documentation/index.html   |   Site Map   |   Search   |   PDF Files   |   Contact   |   Glossary
Tuxedo Doc Home   |   Programming   |   Topic List   |   Previous   |   Next   |   Contents

   Programming a BEA Tuxedo Application Using C

Multithreaded and multicontexted applications are appropriate for some BEA Tuxedo domains, but not all. To decide whether to create such applications, you should answer several basic questions about the following:

• Your development and run-time environments

• Design requirements for your application

• Type of threads model to use

• Interoperability restrictions for Workstation clients

Environment Requirements

When considering the development of multithreaded and/or multicontexted applications, examine the following aspects of your development and run-time environments:

• Do you have an experienced team of programmers capable of writing and debugging multithreaded and multicontexted programs that successfully manage concurrency and synchronization?

• Are the multithreading features of the BEA Tuxedo system supported on the platform on which you are developing your application? These features are supported only on platforms with an OS-provided threads package, providing an appropriate level of functionality.

• Do the resource managers (RMs) used by your servers support multithreading? If so, consider the following issues, as well:

  • Do you need to set any parameters required by your RM to enable multithreaded access by your servers? For example, if you use an Oracle database with a multithreaded application, you must set the THREADS=true parameter as part of the OPENINFO string passed to Oracle. By doing so, you make it possible for individual threads to operate as separate Oracle associations.

  • Does your RM support a mixed mode of operation? A mixed-mode operation is a form of access such that multiple threads in a process can map to one RM association while other threads in the same process simultaneously map to different RM associations. Within one process, for example, Threads A and B map to RM Association X, while Thread C maps to RM Association Y.

    Not all RMs support mixed-mode operation. Some require all threads in a given process to map to the same RM association. If you are designing an application that will make use of transactional RM access within application-created threads, make sure your RM supports mixed-mode operation.

Design Requirements

When designing a multithreaded and/or multicontexted application, you should consider the following design questions:

• Is the task performed by your application suitable for multithreading and/or multicontexting?

• Do you want to connect to more than one BEA Tuxedo application? How many connections to each target application do you want?

• What synchronization issues need to be addressed in your application?

• Will you need to port your application to another platform after you have put your initial application into production?

Is the Task of Your Application Suitable for Multithreading and/or Multicontexting

The following table provides a list of questions to help you decide whether your application would be improved if it were multithreaded and/or multicontexted. This list is not comprehensive; your individual requirements will determine other factors that should be considered.

For additional suggestions, we recommend that you consult a multithreaded and/or multicontexted programming publication.

If the answer to this question . . .	Is YES, then you might consider using . . .
Does your client need to connect to more than one application without using the Domains feature?	Multicontexting
Does your client perform the role of a multiplexer within your application? For example, have you designated one machine in your application the "surrogate" for 100 other machines?	Multicontexting
Does your client use multicontexting?	Multithreading. By allocating one thread per context, you can simplify your code.
Does your client perform two or more tasks that can be executed independently for a long time such that the performance gains from concurrent execution outweigh the costs and complexities of threads synchronization?	Multithreading
Do you want one server to process multiple concurrent requests?	Multithreading. Assign a value greater than 1 to MAXDISPATCHTHREADS. This value enables multiple clients, each in its own thread, for the server.
If your client or server had multiple threads, would it be necessary to synchronize them after each thread had performed only a little work?	Not using multithreading

Decide how many applications you want to access and the number of connections you want to make.

• If you want connections to more than one application, then we recommend one of the following:

  • A single-threaded, multicontexted application

  • A multithreaded, multicontexted application

• If you want more than one connection to an application, then we recommend a multithreaded, multicontexted application.

• If you want only one connection to one application, then we recommend one of the following:

  • Multithreaded, single-contexted clients

  • Single-threaded, single-contexted clients

    In both cases, multithreaded, multicontexted servers may be used.

What Synchronization Issues Need to Be Addressed

This issue is an important one during the design phase. It is, however, beyond the scope of this documentation. Please refer to a publication about multithreaded and/or multicontexted programming.

If you may need to port your application in the future, you should keep in mind that different operating systems have different sets of functions. If you think you may want to port your application after completing the initial version of it on one platform, remember to consider the amount of staff time that will be needed to revise the code with a different set of functions.

Various models for multithreaded programs are now being used, including the following:

• Boss/worker model

• Siblings model

• Workflow model

We do not discuss threads models in this documentation. We recommend that you research all available models and consider your design requirements carefully when choosing a programming model for your application.

Interoperability between Release 7.1 Workstation clients and applications based on pre-7.1 releases of the BEA Tuxedo system is supported in any of the following situations:

• The client is neither multithreaded nor multicontexted.

• The client is multicontexted.

• The client is multithreaded and each thread is in a different context

A BEA Tuxedo Release 7.1 Workstation client with multiple threads in a single context cannot interoperate with a pre-7.1 release of the BEA Tuxedo system.

• Advantages and Disadvantages of a Multithreaded/Multicontexted Application

• Preliminary Guidelines for Programming a Multithreaded/Multicontexted Application