JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for C Clients
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Using the C API

3.  Client Design Issues

Producers and Consumers

Using Selectors Efficiently

Determining Message Order and Priority

Managing Threads

Message Queue C Runtime Thread Model

Concurrent Use of Handles

Single-Threaded Session Control

Connection Exceptions

Managing Physical Destination Limits

Managing the Dead Message Queue

Factors Affecting Performance

Delivery Mode (Persistent/Non-persistent)

Use of Transactions

Acknowledgement Mode

Durable and Non-Durable Subscriptions

Use of Selectors (Message Filtering)

Message Size

Message Type

4.  Reference

A.  Message Queue C API Error Codes

Index

Managing Threads

This section addresses a number of thread management issues that you should be aware of in designing and programming a Message Queue C client. It covers the following topics:’

Message Queue C Runtime Thread Model

The Message Queue C-API library creates the threads needed to provide runtime support for a Message Queue C client. It uses NSPR (Netscape Portable Runtime) GLOBAL threads. NSPR GLOBAL threads are fully compatible with native threads on each supported platform. Message Queue C Runtime Thread Model shows the thread model that the NSPR GLOBAL threads map to on each platform. For more information on NSPR, please see

http://www.mozilla.org/projects/nspr/

Table 3-1 Thread Model for NSPR GLOBAL Threads

Platform
Thread Model
Solaris
pthreads
Linux
pthreads
AIX
pthreads
Windows
Win32 threads (from Microsoft Visual C++ runtime library msvcrt)

Concurrent Use of Handles

Table 3-2 lists the handles (objects) used in a C client program and specifies which of these may be used concurrently and which can only be used by one logical thread at a time.

Table 3-2 Handles and Concurrency

Handle
Supports Concurrent Use
MQDestinationHandle
YES
MQConnectionHandle
YES
MQSessionHandle
NO
MQProducerHandle
NO
MQConsumerHandle
NO
MQMessageHandle
NO
MQPropertiesHandle
NO

Single-Threaded Session Control

A session is a single-threaded context for producing and consuming messages. Multiple threads should not use the same session concurrently nor use the objects it creates concurrently. The only exception to this occurs during the orderly shutdown of the session or its connection when the client calls the MQCloseSession or the MQCloseConnection function. Follow these guidelines in designing your client:

The Message Queue C runtime library provides one thread to a session in MQ_SESSION_ASYNC_RECEIVE mode for asynchronous message delivery to its consumers. When the connection is started, all its sessions that have created asynchronous consumers are dedicated to the thread of control that delivers messages. Client code should not use such a session from another thread of control. The only exception to this is the use of MQCloseSession and MQCloseConnection.

Connection Exceptions

When a connection exception occurs, the Message Queue C library thread that is provided to the connection calls its MQConnectionExceptionListenerFunc callback if one exists. If an MQConnectionExceptionListenerFunc callback is used for multiple connections, it can potentially be called concurrently from different connection threads.

You should not call the MQCloseConnection function in an MQConnectionExceptionListenerFunc callback. Instead the callback function should notify another thread to call MQCloseConnection and return.