Default messaging provider queue connection factory [Settings]

As a convention, use a JNDI name of the form jms/Name, where Name is the logical name of the resource. For more information about the use of JNDI and its syntax, see the topic JNDI support in WebSphere® Application Server.

This indicates the name of a target that is to be used to determine one or messaging engines to handle work. The type of target is indicated by the Target type property

Connections are load balanced across the available messaging engines that satisfy the selection criteria.

If want applications to be able to connect to any messaging engine in the bus, do not set this property.

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

If the selected messaging engine is in the same server as the application, a direct in-process connection is made and this transport chain property is ignored.

You only have to modify this property if you have client applications running outside of an application server, or applications on a server in another cell, that want to use this connection factory to connect to the target service integration bus specified on the connection factory.

To use JMS destinations of the default messaging provider, an application connects to a messaging engine on the target service integration bus to which the destinations are assigned. For example, a JMS queue is assigned to a queue destination on a service integration bus.

Client applications running outside of an application server - for example, running in a client container or outside the WebSphere Application Server environment - cannot locate directly a suitable messaging engine to connect to in the target bus. Similarly, an application running on a server in one cell to connect to a target bus in another cell cannot locate directly a suitable messaging engine to connect to in the target bus.

In these scenarios, the clients (or servers in another bus) must complete a bootstrap process through a bootstrap server that is a member of the target bus. A bootstrap server is an application server running the SIB Service, but does not have to be running any messaging engines. The bootstrap server selects a messaging engine that is running in an application server that supports the required target transport chain. For the bootstrap process to be possible, you must configure one or more provider end points in the connection factory used by the client.

A bootstrap server uses a specific port and bootstrap transport chain. The port is the SIB_ENDPOINT_ADDRESS (or SIB_ENDPOINT_SECURE_ADDRESS if security is enabled), of the messaging engine that hosts the remote end of the link. Together with host name, these form the endpoint address of the bootstrap server.

The properties of a JMS connection factory used by an application control the selection of a suitable messaging engine and how the application connects to the selected messaging engine.

• If no security credentials are provided, then by default
  • If no host is specified then localhost is used
  • If no port is specified then port 7276 is used
  • If no bootstrap channel chain is specified then bootstrap transport chain called BootstrapBasicMessaging is used
• If security credentials are provided, then by default
  • If no host is specified then localhost is used
  • If no port is specified then port 7286 is used
  • If no bootstrap channel chain is specified then bootstrap transport chain called BootstrapBasicMessaging is used

Note: For the IBM® i platform, you must (at least) change the default host name from localhost to your.server.name.

If you want an application to use a bootstrap server with a different endpoint address, you must specify the required endpoint address on the Provider endpoints property of the JMS connection factories that the client application uses. You can specify one or more endpoint addresses of bootstrap servers.

The endpoint addresses for bootstrap servers must be specified in every JMS connection factory that is used by applications outside of an application server. To avoid having to specify a long list of bootstrap servers, you can provide a few highly-available servers as dedicated bootstrap servers. Then you only have to specify a short list of bootstrap servers on each connection factory.

boothost1:7278:BootstrapBasicMessaging
or 
boothost1:7278

boothost2:7289:BootstrapTunneledSecureMessaging

[ [host_name] [ : [port_number] [ : chain_name] ] ]

Specifying host_name : chain_name instead of host_name : : chain_name (with two colons) is incorrect. It is valid to enter nothing, or to enter any of the following: a, a:, :7276, ::chain, and so on. The default value applies if you do not specify a value, but you must separate the fields with :.

boothost1:7278:BootstrapBasicMessaging, 
  boothost2:7289:BootstrapTunneledSecureMessaging, 
  [2002:914:fc12:179:9:20:141:42]:7276:BootstrapBasicMessaging

For more information about using this property with other connection factory properties for workload management of connections, see the topic Administrative properties for JMS connections to a bus.

Messages that are assigned to a consumer are locked on the server and cannot be consumed by any other consumers for that destination. Messages that are assigned to a consumer, but not consumed before that consumer is closed, are subsequently unlocked on the server and then available for receipt by other consumers.

You can override this property for individual JMS destinations by setting the Read ahead property on the JMS destination.

• The application does not modify the data object contained in a JMS object message.
• The application populates a JMS bytes message by using a single call to writeBytes(byte[]) and does not modify the byte array after it is set in the message.

When enabled, Object/Bytes Messages sent by a message producing application that has connected to the bus using this connection factory will not have their data copied when set and the system will only serialize the message data when absolutely necessary. Applications sending such messages must not modify the data once it has been set into the message.

• The application does not modify the data object obtained from a JMS object message. The data object is treated as read only.

When enabled, Object Messages received by a message consuming application that has connected to this connection factory will only have their message data serialized by the system when absolutely necessary. The data obtained from these messages must be treated as readOnly by applications.

Select this property to log connections being created without a transaction context.

This option is used as part of the task to enable container-managed persistence (CMP) entity beans to share the database connections used by the data store of a messaging engine. This has been estimated as a potential performance improvement of 15% for overall message throughput, but can only be used for entity beans connected to the application server that contains the messaging engine. This option must not be enabled for a messaging engine that uses file store as its data store.

For more information about using this option, see the topic Enabling CMP entity beans and messaging engine data stores to share database connections.

This property provides a list of the JCA authentication data entry aliases that have been defined to WebSphere Application Server. You can select a data entry alias to be used to authenticate during XA recovery processing.

If you have enabled security for the associated service integration bus, select the alias that specifies the user ID and password used for XA recovery that is valid in the user registry for WebSphere Application Server. This property must be set if bus security is enabled and XA transactions are to be used.