Automatically Enlisting Transactions Container-Managed Security

Enhanced Support for Using WebLogic JMS with EJBs and Servlets 4-7 ■ Section 4.3.1, Automatically Enlisting Transactions ■ Section 4.3.2, Container-Managed Security ■ Section 4.3.3, Connection Testing ■ Section 4.3.4, Java EE Compliance ■ Section 4.3.5, Pooled JMS Connection Objects ■ Section 4.3.6, Monitoring Pooled Connections

4.3.1 Automatically Enlisting Transactions

This feature works for either WebLogic JMS implementations or for third-party JMS providers that support two-phase commit transactions XA protocol. If a wrapped JMS connection sends or receives a message inside a transaction context, the JMS session being used to send or receive the message is automatically enlisted in the transaction through the XA capabilities of the JMS provider. This is the case whether the transaction was started implicitly because the JMS code was invoked inside an EJB with container-managed transactions enabled, or whether the transaction was started manually using the UserTransaction interface in a servlet or an EJB that supports bean-managed transactions. However, if an EJB or servlet attempts to send or receive a message inside a transaction context and the JMS provider does not support XA, the send or receive call throws the following exception: [J2EE:160055] Unable to use a wrapped JMS session in the transaction because two-phase commit is not available. Therefore, if you are using a JMS provider that doesnt support XA to send or receive a message inside a transaction, either declare the EJB with a transaction mode of NotSupported or suspend the transaction using one of the JTA APIs.

4.3.2 Container-Managed Security

WebLogic JMS uses the security credentials that are present on the thread when the EJB or servlet container is invoked. For foreign JMS providers, however, when you declare a JMS connection factory via a resource-ref element in the ejb-jar.xml or web.xml file, there is an optional sub-element called res-auth. This element may have one of two settings: Container — When you set the res-auth element to Container, security to the JMS provider is managed by the Java EE container. In this case, if the JMS connection factory was mapped into the JNDI tree using a Foreign JMS Connection Factory configuration MBean, then the user name and password from that MBean is used. Otherwise, WebLogic Server connects to the provider with no user name or password specified and throws an error if the createConnection method is used to pass a a user name and password to the connection factory. Application — When you set the res-auth element to Application, any user name or password on the MBean is ignored. Instead, the application code must specify a user name and password to the createConnectionString userName, String password method of the JMS connection factory, or use the version of createConnection with no parameters if user name or password are not required. 4-8 Programming JMS for Oracle WebLogic Server

4.3.3 Connection Testing