BEA Weblogic

Basically, the JMS operation must be done using a transacted session or the transaction must be suspended/disabled as follows (pick one or more of the following).

1. Suspend the current transaction prior to making the JMS call and resume it after completing it. The code looks something like this:

import javax.transaction.Transaction;

import javax.transaction.TransactionManager;

TransactionManager tranManager=

TxHelper.getTransactionManager();

Transaction saveTx = null;

try {

saveTx = tranManager.suspend();

... do JMS work, it will not participate in transaction

} finally {

// must always resume suspended transactions!

if (saveTx != null) tranManager.resume(saveTx);

}

2. Use a transacted session by specifying true for the first parameter to createQueueSession or createTopicSession.

3. Use a connection factory with user transactions disabled. That is, check that the UserTransactionsEnabled flag is explicitly set to false for the connection factory in the config.xml file or use the default for a user-configured connection factory for this value which is false. The pre-configured connection factory weblogic.jms.ConnectionFactory disables user transactions.

A transacted JMS session always has its own inner transaction. It is not affected by any transaction context that the caller may have. A non-transacted JMS session is more complicated. If you use the WLS 6.1 default factory weblogic.jms.ConnectionFactory, the session does not participate in a user transaction because the UserTransactionsEnabled flag is set to "False". If you use the deprecated default factory javax.jms.QueueConnectionFactory or javax.jms.TopicConnectionFactory or you define your own factory and set the UserTransactionsEnabled flag to "True", the JMS session participates in the outer transaction, if one exists and the JMS session is not transacted.

Yes, with one caveat. You may not add new subscribers/consumers to a session if it already has active async consumers. Sessions must only be accessed single-threaded as per the JMS spec. If you feel you need to do this, create a new Session and add it to that one instead.

You can add receivers to a started connection. A receiver in itself is not asynchronous. You need a listener to make it asynchronous. The first creation of a receiver is always safe. If you then add a listener for that first receiver, you have to worry for any future receivers in that same session. You can create new sessions and the first receiver for that session with no worries.

Once you want to create a second receiver in a session, if the first receiver has a MessageListener, you have to take care to make sure there are no other threads of execution in that session. You can do this by stopping the connection or actually creating your receiver from the onMessage routine of the first receiver.

There are no special primitives for doing this. Here are two possible solutions.

One approach is to use multiple sessions as in the following:

while (true) {

Create a session, subscribe to one message on durable

subscription

Close session

Save session reference in memory

To acknowledge the message, find the session reference and call

acknowledge() on it.

}

Another solution is to use transactions and suspend the work as follows:

start transaction

while(true) {

message = receive();

if (message is one that I can handle)

process the message

commit

} else {

suspend transaction

put transaction aside with message

start transaction

}

}

To "acknowledge" the message:

resume user transaction

commit

To "recover" the message:

resume user transaction

rollback

Each time you suspend, you need to push the transaction onto a stack or list possibly with the message so you can process it or roll it back later. This solution is high overhead in that there can be a large build up of outstanding transactions. Note that transactions have timeouts and it may rollback on its own, which means you can get the message again (in a different transaction). Note also that there are some practical limits on the number of transactions you should leave outstanding. The default limit is something like 10000. Eventually you want to go back to your stack/list and commit/rollback the transactions. Note that transaction references (javax.transaction.Transaction) are not Serializable.

a. Waiters high

b. Waiters

c. Connections high

d. Clients

e. Wait seconds high

Choice B is correct. JDBC subsystem resources can also be monitored via the Administration Console. The Monitoring tab for a JDBC connection pool allows you to access a table listing statistics for the instances of that pool. These attributes provide important information for managing client database access.

The Waiters High field indicates the highest number of clients waiting for a connection at one time. The Waiters field tells you how many clients are currently waiting for a connection. The Connections High field indicates the highest number of connections that have occurred at one time. The Wait Seconds High field tells you the longest duration a client has had to wait for a database connection. These attributes allow you to gauge the effectiveness of the current configuration in responding to client requests.

If your application design requires messages to be received synchronously, we recommend using one of the following methods listed in order of preference:

* Pass a timeout value as an argument to the receive() method and set it to the minimum value greater than zero, that is allowed by the application to avoid consuming threads that are waiting for a response from the server.

* Use the receiveNoWait() method which returns the next message or a null value if no message is currently available. In this case, the call does not block. The servlet should provide a way to return to or reschedule the request, without calling wait().

Note: Use of this option should be minimized, as it may deadlock a busy server.

* Ensure that more threads are configured than the number of possible simultaneous blocking receive() calls.

Multicasting enables the delivery of messages to a select group of hosts that subsequently forwards the messages to multicast subscribers. The benefits of multicasting include:

* Near real-time delivery of messages to host group.

* High scalability due to the reduction in the amount of resources required by the JMS server to deliver messages to multicast subscribers.

Note: Multicasting is only supported for the Pub/sub messaging model.

For an example of when multicasting might be useful, consider a stock ticker. When accessing stock quotes, timely delivery is more important than reliability. When accessing the stock information in real-time, if all, or a portion, of the contents is not delivered, the client can simply request the information be resent. Clients would not want to have the information recovered in this case because by the time it is redelivered it would be out-of-date.

Multicast messages are not guaranteed to be delivered to all members of the host group. For messages requiring reliable delivery and recovery, you should not use multicasting.

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).

a. A single JMS store can support multiple JMS servers.

b. Multiple consumers may consume from the same queue, but multiple producers may not send to the same queue.

c. Multiple JMS Servers may exist on one WebLogic 6.0 server.

d. A JMS Server can be deployed on only one server.

Choices C and D correct. JMS is an enterprise messaging system, which enables applications to communicate with one another through the exchange of messages. WebLogic JMS provides a full implementation of the JMS API.JMS objects are the objects necessary to connect to the JMS, and send and receive messages.

The major components of the WebLogic JMS Server architecture include WebLogic JMS servers implementing the messaging facility, Client applications, JNDI and Backing stores (file or database) for storing persistent data. Two or more JMS servers cannot share the same persistent store. Each JMS server must have its own unique persistent store. Two file-based JMS persistent stores may share the same directory, but their messages will be stored in different files. Multiple consumers may consume from the same queue and multiple producers may send messaged to the same queue. Multiple JMS servers may exist on the same WebLogic server, but a JMS server can be deployed only on server at a time.

Due to a limitation in the JMS 1.0.2 specification, asynchronous messages can become deadlocked if the close() method of a session is inside a user-synchronized block. To resolve this, you must move the close() method outside the user-synchronized block. For example:

public class CloseTest() {

private void xxx() {

synchronized (this) {

create connection/session/consumer

initialize and set a listener for this consumer;

wait();

connection.close();

}

}

private void onMessage(Message message) {

synchronized (this) {

notify();

}

}

}

Before the connection.close() method is closed, another message can be delivered to the onMessage routine by the JMSProvider. The main() method thread owns the monitor lock for the CloseTest method. Before the onMessage() method of the CloseTest class fires, JMS sets INLISTENER as the state for the session in JMSSession (the JMS specification says that the close() method must wait for the onMessage routine), so that the main() method thread can wait for the onMessage routine to complete.

Now when the onMessage routine tries to acquire the monitor lock, it blocks waiting for the main() method thread to give up, and the main() method thread is waiting for the onMessage to be completed.

JMS also blocks when the close() method of a consumer is done from an onMessage routine and the allowCloseInOnMessage attribute is set to false in the config.xml file.

If you wish to issue the close() method within an onMessage() method call, the system administrator must select the Allow Close In OnMessage check box when configuring the connection factory. For more information, see JMS Connection Factories in the Administration Console Online Help. If this check box is not selected and you issue the close() method within an onMessage() method call, the call will hang.

The close() method performs the following steps to execute an orderly shutdown:

* Terminates the receipt of all pending messages. Applications may return a message or null if a message was not available at the time of the close.

* Waits until all message listeners that are currently processing messages have completed (except for the message listener from which the close() method is being called).

* Rolls back in-process transactions on its transacted sessions (unless such transactions are part of an external JTA user transaction).

* Does not force an acknowledge of client-acknowledged sessions. By not forcing an acknowledge, no messages are lost for queues and durable subscriptions that require reliable processing.

When you close a connection, all associated objects are also closed. You can continue to use the message objects created or received via the connection, except the received message's acknowledge() method. Closing a closed connection has no effect.

Note: Attempting to acknowledge a received message from a closed connection's session throws an IllegalStateException.

When you close a session, all associated producers and consumers are also closed.

For more information about the impact of the close() method for each object, see the appropriate javax.jms javadoc.

a. The weblogic/config/examples/applications directory acts as an automatic deployment directory for EJB 2.0 .jar files and EJB .jar deployment directories

b. The automatic redeployment feature of the WebLogic Server can only redeploy an EJB's implementation classes, you cannot redeploy an EJB's public interfaces

c. Before deploying a packaged jar file containing uncompiled EJB classes and interfaces, we have to use weblogic.ejbc on the packaged .jar file to generate WebLogic Server container classes.

Choice C is correct because it is NOT true. A and B are true about deploying EJBs in the WebLogic server. The weblogic/config/examples/applications directory acts as an automatic deployment directory for EJB 2.0 .jar files and EJB .jar deployment directories. When you start WebLogic Server, it automatically deploys any valid EJB 2.0 .jar files or .jar directories that reside in the applications directory. WebLogic Server also checks the contents of applications every ten seconds to determine whether an EJB deployment has changed. If a deployment has changed, it is automatically redeployed using the dynamic deployment feature.

If you change the contents of a compiled EJB .jar file in applications, WebLogic Server automatically attempts to redeploy the .jar using the dynamic deployment feature. Since the automatic redeployment feature uses dynamic deployment, WebLogic Server can only redeploy an EJB's implementation classes. You cannot redeploy an EJB's public interfaces. You create compiled EJB 2.0 .jar files by Compiling your EJB classes and interfaces, packaging the EJB classes and interfaces into a valid .jar file and then Using weblogic.ejbc on the .jar file to generate WebLogic Server container classes. An uncompiled EJB .jar file has the same structure as a compiled file, but you do not have to compile individual class files and interfaces and you do not have to use weblogic.ejbc on the packaged .jar file to generate WebLogic Server container classes. So C is not true.

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.

There are some additional configuration requirements for the messaging bridge to handle transactions between WebLogic domains:

* The supported adapters are located in the WL_HOMElib 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.

You can enable debugging for the messaging bridge using either of the followings methods:

* Add the following lines to your WebLogic start script (before the weblogic.Server line):

-Dweblogic.Debug.DebugMessagingBridgeStartup=true

-Dweblogic.Debug.DebugMessagingBridgeRuntime=true

* Add the following statements to the ServerDebug entry in your configuration file (config.xml) for the server that the messaging bridge is running on:

DebugMessagingBridgeStartup="true"

DebugMessagingBridgeRuntime="true"

Once debugging is enabled for the messaging bridge, the debugging messages are sent to the server log by default. However, if you want them to appear in the Administration Console, add "DumpToConsole" to the statements show above. For example:

-Dweblogic.Debug.DebugMessagingBridgeStartupDumpToConsole=true