WebSphere Message Brokers
File: ac00406_
Writer: Karen Cameron

Concept topic

This build: July 31, 2007 21:16:35

User database connections

User databases contain your business data. If a message flow application is configured to access a user database, you must define a connection from the broker to the user database.

The broker makes a database connection to the ODBC data source name (DSN) for each DSN even if different DSNs resolve to the same physical database.

The number of connections to a user database that a broker requires depends on the actions of the message flows that access the database. For each message flow thread, a broker that accesses a user database makes one connection for each ODBC data source name (DSN). If a different node on the same thread uses the same DSN, the same connection is used, unless a different transaction mode is used, in which case another connection is required. This is explained further in Database connections for coordinated message flows.

When you start a broker, and while it is running, it opens connections to WebSphere MQ queues and to databases. The broker makes the connections when it needs to use them, and they remain open until:

Database connections from message flows that are not globally coordinated are released when a flow has no work. For example, a connection is released if there are no messages on a message flow's input queue, and the database has not been accessed for one minute.

On Windows, UNIX, and Linux, to avoid breaking global coordination, database connections are released only for message flows that are not globally coordinated.

z/OS platform Additionally on z/OS, database connections for globally coordinated message flows are released if the database has not been accessed for one minute.

If you are using the same database for business data and for broker internal data, add the two connection requirements together when you calculate how many connections are required. For details of broker database connection requirements, see Broker database connections.

If you stop the broker, it releases all current database connections.

If you are using DB2 for your database, DB2's default action is to limit the number of concurrent connections to a database to the value of the maxappls configuration parameter. The default for maxappls is 40. If you believe that the connections that the broker might require exceeds the value for maxappls, increase this and the associated parameter maxagents to new values based on your calculations.

If you are using another database, check the database documentation for information about connections and limits or restrictions.

When a message flow is idle, the execution group periodically releases database connections. Therefore, connections held by the broker reflect the broker's current use of these resources. This allows the broker to respond to database quiesce, where the database manager supports quiescing. Not all databases support the quiesce function, and not all databases quiesce in the same way. Check your database documentation for information about database quiescing.

32-bit and 64-bit considerations

If a message flow that accesses the user database is deployed to a 32-bit execution group, you must define a 32-bit ODBC data source name (DSN) for the user database so that the broker can connect to the user database on behalf of the message flow.

If the message flow is deployed to a 32-bit execution group and the message flow transactions are globally coordinated by a 64-bit queue manager (all WebSphere MQ Version 6 queue managers on 64-bit platforms are 64-bit), you must define both a 32-bit ODBC DSN and a 64-bit ODBC DSN for the user database (you must also define a 64-bit ODBC DSN for the broker database; see Broker database connections).

If a message flow that accesses the user database is deployed to a 64-bit execution group, you must define a 64-bit ODBC DSN for the user database so that the broker can connect to the user database on behalf of the message flow. You cannot use a 32-bit queue manager to globally coordinate a message flow that is deployed to a 64-bit execution group so you do not need to define a 32-bit ODBC DSN for the user database.

For 32-bit and 64-bit considerations when connecting to the broker database, see Broker database connections.

For help when you are deciding whether to create 32-bit DSNs, 64-bit DSNs, or both for your user databases, see Enabling connections to the databases.

Related concepts
Broker database connections
Related tasks
Enabling connections to the databases
Accessing databases from message flows
Configuring globally coordinated message flows
Related reference
Supported databases
Support for UNICODE and DBCS data in databases
Database connections for coordinated message flows
Listing database connections that the broker holds
Quiescing a database
WebSphere MQ connections
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:16:35

ac00406_ This topic's URL is: