Set - 2

Question 16 :

Which types of JDBC databases does WebLogic JMS support?

Answer :

The JMS database can be any database that is accessible through a JDBC driver. WebLogic supports and provides JDBC drivers for the following databases:
* Cloudscape
* Informix
* Microsoft SQL (MSSQL) Server (Versions 6.5 and 7)
* Oracle (Version 8.1.6)
* Sybase (Version 12)


Question 17 :

How do I use a third-party JDBC driver with JMS?

Answer :

If your JDBC driver is not included in the list of drivers in the question about JDBC databases supported by WebLogic JMS, then the tables required by JMS must be created manually.

Note: WebLogic Server only guarantees support for the JDBC drivers included in the previous list. Support for any other JDBC driver is not guaranteed.

The .ddl files located in the weblogic/jms/ddl directory of the weblogic.jar file may be used as templates. Use the jar utility supplied with the JDK to extract them to the weblogic/jms/ddl directory using the following command:

jar xf weblogic.jar weblogic/jms/ddl

Note: If you omit the second parameter (weblogic/jms/ddl), the entire jar file is extracted.
Follow the procedures in JDBC Database Utility in Programming WebLogic JMS to manually create the database tables for the JDBC store.
Another option is to consider using a file store instead of a JDBC store. File stores are easier to configure and may provide significantly better performance.


Question 18 :

How do I use persistence?

Answer :

Use the following guidelines:
1. Make sure the JMSServer you are using has a store configured. The JMSServer configuration entry in the config.xml file should contain a line of the form

Store=""
Note that if JMS boots without a store configured, it is assumed the customer did not want one, and persistent messages are silently downgraded to non-persistent (as specified for JMS 1.0.2).
2. Make sure you are not using "Message.setJMSDeliveryMode". This is overwritten, as it is a vendor-only method.
3. Make sure you are calling either:
QueueSender.send(msg, deliveryMode, ...)
-- or --
QueueSender.setDeliveryMode(deliveryMode)
-- or --
set the DefaultDeliveryMode mode on connection factory in the config.xml file to persistent (the QueueSender.setDeliver/send overrides this value). Similarly, for topics, you would set this via the TopicPublisher.
4. Make sure you don't have "DeliveryModeOverride" set to Non-Persistent on the Destination in the config.xml file.
5. If you are using pub/sub, only durable subscriptions persist messages. Non-durable subscriptions have no need to persist messages, as by definition they only exist for the life of the server.
6. If you are using JDBC, the JDBC tables, JMSSTATE and JMSSTORE, are created automatically when the JMS server boots. The DDL files used to create the tables are stored in weblogic.jar in weblogic/jms/ddl. The example configuration below shows a JDBC store for Oracle (client version 8.1.7 or later is needed to run with WLS 6.1 on JDK 1.3). To manually create the tables (also deleting any existing tables), run java utils.Schema as described in the previous question.
See the question, "How do I start WLS and configure JMS?" for a description of how to configure JMS.
Here is a sample config.xml file resulting from configuring JMS. It should look similar to yours. If you want JMS to use a file store instead of a database, just change JDBCStore to FileStore in the JMSServer section.




Targets="myserver" Store="JDBCStore">







The following is a sample class that sends
a Topic message on construction:

import javax.naming.*;
import javax.jms.*;
import java.util.Hashtable;

public class t

{
public final static String DESTINATION="jms.topic.TestTopic1";

private TopicConnectionFactory connectionFactory;
private TopicConnection connection;
private TopicSession session;
private TopicPublisher producer;
private TextMessage message;
private Topic destination;

public t()
{
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
InitialContext ctx = new InitialContext(env);
destination = (Topic) ctx.lookup(DESTINATION);
connectionFactory = (TopicConnectionFactory)
ctx.lookup("javax.jms.TopicConnectionFactory");
connection = (TopicConnection)
connectionFactory.createTopicConnection();
session = (TopicSession) connection.createTopicSession(false,

Session.AUTO_ACKNOWLEDGE);
producer = (TopicPublisher) session.createPublisher(destination);
producer.setDeliveryMode(DeliveryMode.PERSISTENT);
message = (TextMessage) session.createTextMessage();
message.setText("hello world");
producer.publish(message);
} catch (Exception e) {
}
}
}


Question 19 :

How does a file store compare with a JDBC store?

Answer :

The following are some similarities and differences between file stores and JDBC stores:
* Both have the same transaction semantics, including rolling back transactions (e.g., received messages are put back on the queue).
* Both have the same application interface (no difference in application code).
* The file store should be much faster.
* JDBC may make it easier to handle failure recovery since the JDBC interface can access the database from any client machine; with the file store, the disk must be shared or migrated.
* File store reliability is limited to reliability of disk and O/S; run it on Veritas or a RAID 5 system. Database reliability may be higher.
* File stores will require more memory, but perhaps not significantly more; it depends on how fragmented the file store gets, if the application works roughly
* FIFO it shouldn't get very fragmented at all.
* File stores generate no additional network traffic, database stores do if the database server is on a different JVM or machine.


Question 20 :

How do the WLS JMS 6.1 server/destination message maximum and threshold values work?

Answer :

The byte and message maximum values are quotas - not flow control. Message quotas prevent a WebLogic JMS server from filling up with messages and possibly running out of memory, causing unexpected results. When you reach your quota, JMS prevents further sends with a ResourceAllocationException (rather than blocking). You can set quotas on individual destinations or on a server as a whole.
The thresholds are also not flow control - though they would be better suited to that application than the quotas. The thresholds are simply settings that when exceeded cause a message to be logged to the console to let you know that you are falling behind.
Note that the messages maximum setting on a connection factory is not a quota. This specifies the maximum numbers of outstanding messages that can exist after they have been pushed from the server but before an asynchronous consumer has seen them; it defaults to a value of 10.