Set - 3

Question 26 :

Can you use a foreign JMS provider to drive an MDB transactionally?

Answer :

No. The message is asynchronously received outside a transaction and there is no J2EE API to then associate the message with a transaction.
The only reason this works for WebLogic Server JMS is that we have defined a WebLogic Server extension interface that has a method to associate a message with a transaction. This interface, MDBTransaction, is defined in news://newsgroups.bea.com/3b3a009b$1@newsgroups.bea.com. It has one method, associateTransaction(), that takes a javax.jms.Message parameter. This message must be associated with the transaction. We are hoping that other JMS vendors interested in integrating with WebLogic Server will implement this interface.
Another approach called source managed transactions, would be for there to be an API to tell the JMS provider to start a transaction on your behalf before delivering the message to an asynchronous consumer. This API doesn't exist in J2EE either. Even if there were such a provision, few non-WLS JMS providers can begin and drive such a transaction by themselves.
The current solution is to move all messages from the foreign destination to a WebLogic Server JMS destination (within a transaction if the foreign JMS provider supports it) and have that WebLogic Server JMS destination drive the MDB transactionally (using the WLS JMS special interface). Currently, the messages can be moved between providers using code similar to that described in the "Using Foreign JMS Providers With WebLogic Server" white paper. This code could be contained in a startup class that starts a thread and does the following:
while (true) {
start a transaction
receive a message synchronously with timeout
if timed_out { rollback and continue }
do the work
commit the transaction }

Doing a synchronous receive will have a problem in that the transaction may time out before the message is received. You can do the receive with a specified timeout, allowing enough time left in the transaction to complete the work. If the receive fails, roll back the transaction and try again. It is also not as efficient as MDBs since it does a synchronous instead of asynchronous receive (it ties up threads). Also, if you get a lot of timeouts, you will be burning more CPU.
Eventually, WLS JMS will provide a bridge to handle this message passing out-of-the box.
With any of these approaches, the XAResource must be registered with the Transaction Manager (this is done automatically for WebLogic Server JMS).


Question 27 :

How do I use JTA transactions within an MDB?

Answer :

In the ejb-jar.xml file, define the transaction type as Container and the trans-attribute as Required, as in the following example:



MDB
MDB
Container

javax.jms.Queue






MDB
*


Required





To rollback a transaction, you can either use the WebLogic extension TXHelper or you can use the MDB context as in the following code examples:
UserTransaction ut =
weblogic.transaction.TXHelper.getUserTransaction();
ut.setRollbackOnly();

or
private MessageDrivenContext context;
public void setMessageDrivenContext(
MessageDrivenContext mycontext) {
context = mycontext;
}
public void onMessage(Message msg) {
try { // some logic
}
catch(Exception e) {
System.out.println("MDB doing rollback");
context.setRollbackOnly();
}


Question 28 :

Why did the messaging bridge fail to connect to the source bridge destination?

Answer :

Either an error occurred when configuring the source bridge destination parameters, or the actual source destination is not running and cannot communicate with the messaging bridge.

* Verify whether the bridge's source destination is correctly configured, by making sure that the following fields on the JMS Bridge Destination —> Configuration —> General console page have been properly completed:

o Connection URL—this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
o Destination JNDI Name—this must be the JNDI name of the actual destination mapped to the source bridge destination.
o Connection Factory JNDI Name—this must be the connection factory used to create a connection for the actual destination mapped to the source bridge destination.
o User Name/Password—make sure that this user ID has permission to access the actual source destination.
* Verify that the actual source queue or topic destination mapped to the source bridge destination is running and healthy, as follows:
o Is the WebLogic Server instance hosting the source destination running?
o Is the JMS server hosting the source destination correctly deployed?

Note: This troubleshooting scenario for correcting a source bridge destination connection failure also applies to target bridge destinations.


Question 29 :

Can the messaging bridge handle two-phase or global transactions between separate WebLogic Server domains or between different releases?

Answer :

Yes, as long as the communication is between source and target WebLogic domains that are both running release 6.1 SP3 or later, and the bridge is configured to use the Exactly-once quality of service.
I configured the messaging bridge to use the Exactly-once quality of service for two-phase transactions. So why am I getting a "quality of service is unreachable" error?
There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:

* The supported adapters are located in the WL_home\lib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 6.1 domain where the bridge is running, via the select Deployments —> Applications node on the console.
* This jms-xa-adp.rar adapter must also be identified in the Adapter JNDI Name attribute as eis.jms.WLSConnectionFactoryJNDIXA on the JMS Bridge Destination —> Configuration tab for both the source and target bridge destinations.
* For WebLogic JMS, verify that you are using the transactional XAConnectionFactory for the queue or topic destinations mapped to both the source and target bridge destinations. To verify this, the following attributes must be set on the JMS —> Connection Factory —> Configuration —> Transactions console tab or in the configuration file (config.xml):
UserTransactionsEnabled=true
XAConnectionFactory=true
* For third-party JMS vendors, verify that you are using a transactional connection factory for the destinations mapped to the source and target bridge destinations.


Question 30 :

Can I configure the messaging bridge to automatically downgrade the quality of service if the Exactly-once service isn't available on either the source or target bridge destination?

Answer :

Yes, just make sure to select the QOS Degradation Allowed check box on the Messaging Bridge —> Configuration —> General administration console page.