Weblogic Server Tutorial | Weblogic Tutorial for Beginners

1. Question: Can I Use a One-Phase Commit If My WebLogic JMS JDBC Store is On the Same Database For Which I am Doing Other Database Work?

Answer: No. WebLogic JMS is its own resource manager. That is JMS itself implements XAResource and handles the transactions without depending on the database (even when the messages are stored in the database). That means whenever you are using JMS and a database (even if it is the same database as the JMS messages are stored) then it is 2PC.
You may find it will aid performance if you ensure the connection pool used for the database work exists on the same server as the JMS queue—the transaction will still be two-phase, but it will be handled with less network overhead. Another performance boost might be achieved by using JMS file stores rather than JMS JDBC stores.

2. Question: When Do WebLogic JMS Operations Take Place as Part of a Transaction Context?

Answer: When WebLogic JMS is used inside the server, JMS sessions may automatically be enlisted in the JTA transaction depending on the setting of various parameters. Prior to release 8.1, WebLogic JMS sessions would automatically be enlisted in the JTA transaction if either of the following two conditions were met:
The XAConnectionFactoryEnabled and UserTransactionsEnabled flags were set on the connection factory.
The XAServerEnabled flag was set on the connection factory.
In WebLogic Server 8.1, it is only necessary to set the XAConnectionFactoryEnabled flag. The old flags are still supported for backward compatibility, however.
When a WebLogic JMS connection factory is registered as a resource-reference inside an EJB, servlet, or JSP, and the connection factory is looked up out of the java: comp/env JNDI tree, then the EJB container checks to make sure that the appropriate flags are set for transaction enlistment. If the WebLogic JMS connection factory does not support automatic transaction enlistment, then the EJB container will throw an exception if a JMS session is used inside a transaction context. When used without a resource-reference however, such as in the case of an EJB that looks up a JMS connection factory directly, without using java: comp/env, then no checking takes place. If the JMS session is used outside a JTA transaction, then no enlistment takes place.
The default connection factory, weblogic.jms.ConnectionFactory does not support automatic transaction enlistment. If you desire this behavior, you must use the weblogic.jms.XAConnectionFactory factory. (The legacy connection factories  javax.jms.QueueConnectionFactory and javax.jms.TopicConnectionFactory supports automatic transaction enlistment as well.

3. Question: Why is My WebLogic JMS Work Not Part of a User Transaction (That is, Called Within a Transaction But Not Rolled Back Appropriately) How Do I Track Down Transaction Problems?

Answer: Usually this problem is caused by explicitly using a transacted session which ignores the external, global transaction by design (a JMS specification requirement). A transacted JMS session always has its own inner transaction. It is not affected by any transaction context that the caller may have.
It may also be caused by using a connection factory that is configured with the XAConnectionFactoryEnabled flag set to false.
1. You can check if the current thread is in a transaction by adding these two import lines:
import javax.transaction.*
import weblogic.transaction.*;
and adding the following lines (i.e., just after the begin and just before every operation).
Transaction tran = TxHelper.getTransaction();
System.out.println(trans);
System.out.println(TxHelper.status2String(tran.getStatus()));
This should give a clear idea of when new transactions are starting and when the infection is occurring.
2. Ensure that the thread sending the JMS message is infected with a transaction. Check that the code is not using a transacted session by setting the first parameter of createQueueSession or createTopicSession to false. Note that creating the connection and/or session is orthogonal to the transaction. You can begin your transaction before or after. You need only start the transaction before you send or receive messages.
3. Check that the XAConnectionFactoryEnabled flag is explicitly set to true for the connection factory in the config.xml file since the default for user-configured connection factories for this value is false. If you are using one of the pre-configured connection factories they are set as follows:
weblogic.jms.ConnectionFactory disables user transactions so don’t use this one for the case where user transactions are desired;
javax.jms.QueueConnectionFactory and javax.jms.TopicConnectionFactory enables user transactions.

4. You can trace JTA operations by starting the server with this additional property:
-WebLogic.Debug.DebugJMSXA=true
You should see trace statements like these in the log:
XA! XA(3163720,487900) <RM-isTransactional() ret=true>
This can be used to ensure that JMS is infected with the transaction.

4. Question: How Do I Integrate Non-WebLogic JMS Providers With WLS?

Answer: Refer to “Simple Access to Remote or Foreign JMS Providers” in the Administration Console Online Help and the “Using Foreign JMS Providers with WebLogic Server” white paper (jmsproviders.pdf) on the JMS topic page, for a discussion on integrating MQ Series, IBus MessageServer, Fiorano, and SonicMQ.

5. Question: How Do I Use HTTP Tunneling?

Answer: If you want to use HTTP tunneling (wrap every message in HTTP to get through a firewall), you need to add TunnelingEnabled=” true” into your definition in the config.xml file or check the appropriate box on the console. Then use a URL likeinstead of t3://localhost:7001 for Context. PROVIDER_URL when getting your InitialContext. If you want HTTP tunneling with SSL, use (where https uses HTTP tunneling with SSL and 7002 is the secure port that you configured). You will pay a performance penalty for doing this, so only use tunneling it if you really need to (i.e., need to go through a firewall).

6. Question: Does the WebLogic JMS Server Find Out About Closed or Lost Connections, Crashes, and Other Problems and Does It Recover From Them?

Answer: Yes, but how it does this depends on whether a Java client crashes or WebLogic Server crashes, as follows: 

If a Java client crashes then the JMS server will clean up all the outstanding server-side resource from the crashed client JVM, such as:

• JMS connection(s) from the crashed client JVM
• JMS temporary destination(s) created under the above  JMS connection(s)
• JMS session(s) created under the above JMS connection(s)
• JMS client(s) created under the above JMS session(s) (connection consumer and regular consumer)
• JMS browser(s) created under the above session(s)
• JMS producer(s) created under the above session(s)

If WebLogic Server crashes and it is the front-end to the JMS server, then:

• A JMS client will lose all the server-side resources listed above.
• The client’s javax.jms.ExceptionListener.onException will be called (if javax.jms.JMSConnection.setExceptionListener is set) with a LostServerException, which extends JMSException.

If WebLogic server crashes and it is a back-end to the JMS server, then:

• A JMS client may partially lose some of the server-side resources listed above (only the resource on the crashed server, such as JMS temporary destination(s), JMS client(s) and JMS browser(s).
• The client’s javax.jms.ExceptionListener.onException(…) will be called (if weblogic.jms.extensions.WLSession.setExceptionListener is set) with a ConsumerClosedException, which extends JMSException. 

7. Question: Why Does JMSSession.CreateTopic or JMSSession.CreateQueue Fail to Create a Destination in WebLogic JMS 8.1 (It Worked in Version 5.1)?

Answer: In WLS 5.1 create topics() or create queues() creates the destination permanently in the database if it doesn’t already exist, but does not modify the WebLogic.properties file. 

According to the JavaSoft JMS specification version 1.0.2 regarding creating a queue() and create a topic(), they are not for creating destinations dynamically. They are used to retrieve the destination referenced by using a string name instead of using a JNDI lookup. The destination has to be in your config.xml file first. This change is documented in WLS 6.0 since it behaves differently than the previous release. You can use the WLS JMS helper class (weblogic.jms.extensions.JMSHelper) or the console to create destinations at the run time (note that there was a bug in 6.0 that caused a problem when the server restarted; this is fixed in Service Pack 1). These mechanisms create the destination and also modify the configuration file.

For more information on the JMSHelper classes, see the subsection called Creating Destinations Dynamically in Programming WebLogic JMS. 

The following program creates a Topic.

import java.io.*;
import java.util.Hashtable;
import javax.jms.*;
import javax.naming.*;
import weblogic.jms.extensions.JMSHelper;

class t {
public final static String
JNDI_FACTORY=”weblogic.jndi.WLInitialContextFactory”;
public final static String JMS_SERVER_NAME=”TestJMSServer”;
public final static String DEST_JNDI_PREFIX=”javax.destination.”;

static public void main(String [] args) throws Exception {
try {
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
env.put(Context.PROVIDER_URL, “t3://localhost:7001”);
Context ctx = new InitialContext(env);

String topicName = “JMSHelperTestQueue01”;
String topicJNDI = DEST_JNDI_PREFIX + topicName;
System.out.println(“topic name=” + topicName + “, jndi=” +
topicJNDI);
JMSHelper.createPermanentTopicAsync(ctx, JMS_SERVER_NAME,
topicName,
topicJNDI);
} catch (JMSException e) {
e.printStackTrace();

8. Question: Is There a Smaller Version of the Weblogic.jar File For Supporting Clients?

Answer: Yes. WebLogic Server 8.1 provides a true J2EE application client. The WebLogic Server application client is provided as a standard client and a JMS client, packaged as two separate jar files—wlclient.jar and wljmsclient.jar—in the /server/lib subdirectory of the WebLogic Server installation directory. Each jar is about 400 KB. 

• For instructions on developing a thin client, see Developing a J2EE Application Client (Thin Client) in Programming WebLogic RMI over IIOP.
• For information about the JMS jar, see WebLogic JMS Thin Client in Programming WebLogic JMS.
• For an overview of client options, see Using RMI over IIOP Programming Models to Develop Applications in Programming WebLogic RMI over IIOP.

9. Question: Is There a C/C++ Interface to WebLogic JMS?

Answer: Yes, there is a JMS C client available on the dev2dev Utility and Tools page, which has a downloadable jmscapi.zip file that includes all the necessary files, as well as documentation and samples. This is not a supported product of BEA. However, if you have questions about this API you can post them to WebLogic JMS “weblogic.developer.interest.jms” newsgroup available on the BEA Newsgroup server.

10. Question: How Do I Use OS Authentication With WebLogic driver For Oracle and Connection Pools?

Answer: Using OS authentication in connection pools essentially means that you are using the UserId of the user who started WebLogic Server. OS authentication is available on Windows and UNIX. This means that database security will rely strictly on the security of WebLogic; that is, if you are allowed to make a client connection to the WebLogic Server and access the pool, then you can get to the database.  

You can do this with WebLogic driver for Oracle because Oracle uses the process owner to determine who is attempting the connection. In the case of WebLogic JDBC, this is always the user that started the WebLogic Server.

To set up your Oracle instance to use this feature, your DBA needs to follow these basic steps. The full procedure is described in more detail in your Oracle documentation. 

Add the following line to the INIT[sid].ORA file:

OS_AUTHENT_PREFIX = OPS$

Note that the string “OPS$” is arbitrary and up to the DBA.

Log in to the Oracle server as SYSTEM.

Create a user named OPS$userid, where userid is some operating system login ID. This user should be granted the standard privileges (for example, CONNECT and RESOURCE).

Once the userid is set up, you can connect with WebLogic jDriver for Oracle by specifying “/” as the username property and “/” as the password property. Here is an example for testing this connection with the dbping utility:

$ java utils.dbping ORACLE “/” “” myserver

Here is a code example for WebLogic jDriver for Oracle:
Properties props = new Properties();

props.put(“user”, “/”);

props.put(“password”, “/”);

props.put(“server”, “myserver”);

Class.forName(“weblogic.jdbc.oci.Driver”).newInstance();

Connection conn = myDriver.connect(“jdbc:weblogic:oracle”,
props);

Use the Administration Console to set the attribute for your connection pool. The following code is an example of a JDBC connection pool configuration using the WebLogic jDriver for Oracle:

JDBCConnectionPool

Name=”myPool”

Targets=”myserver,server1″

DriverName=”weblogic.jdbc.oci.Driver”

InitialCapacity=”1″

MaxCapacity=”10″

CapacityIncrement=”2″

Properties=”databaseName=myOracleDB”

11. Question: What Transaction Isolation Levels Does the WebLogic driver For Oracle Support?

Answer: Your servlet application may use Oracle Thin Drivers to access a database that includes BLOB fields. If you install and try to use WebLogic jDriver for Oracle and the same code fails and produces an exception similar to the following: (What Transaction Isolation Levels Does the WebLogic jDriver For Oracle Support)

com.roguewave.jdbtools.v2_0.LoginFailureException:
TRANSACTION_READ_UNCOMMITTED isolation level not allowed
The Stack Trace:
com.roguewave.jdbtools.v2_0.LoginFailureException:
TRANSACTION_READ_UNCOMMITTED isolation level not allowed
at
com.roguewave.jdbtools.v2_0.jdbc.JDBCServer.createConnection
(JDBCServer.java :46)
at com.roguewave.jdbtools.v2_0.ConnectionPool.getConnection_
(ConnectionPool.jav a:412)
at com.roguewave.jdbtools.v2_0.ConnectionPool.getConnection
(ConnectionPool.java :109)

Setting the Isolation_level to 1 in the code that calls the RogueWave JDBCServer class works with the Oracle thin driver but fails with WebLogic jDriver for Oracle.

WebLogic driver for Oracle supports the following transaction isolation levels:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

According to the Oracle documentation, the Oracle DBMS only supports these two isolation levels. Unlike other JDBC drivers, WebLogic’s drivers throw an exception if you try to use an isolation level that is unsupported. Some drivers silently ignore attempts to set an unsupported isolation level. WebLogic suggests testing whether the Oracle thin driver is not just ignoring settings for unsupported isolation events. 

12. Question: Can the Weblogic JDriver for MSSSQL Server Connect to the Database Server Using a Trusted Connection on NT/WIN2K?

Answer: Our driver doesn’t support trusted connections. 

13. Question: Why Do I Get “java.sql.SQLException: get object is Not Supported By the WebLogic JDBC Driver”?

Answer: When using the WebLogic JDBC connection pool and weblogic.jdbc.vendor.oracle.OracleResultSet, the error is returned (where OBJECT is the name of some Oracle object). It implies that this feature is not supported by WebLogic Server JDBC because the object type is not serializable. There are two alternatives. (Company)

• You can switch to using the Oracle thin driver directly. That means that you will get a connection directly to the database using the Thin driver instead of getting the connection from a pool of JDBC connections. That means that you lose all advantages of using the WebLogic Server JDBC subsystem, such as transactions, connection pooling, and caching of prepared statements.
• BEA recommends moving your processing to a stored procedure. 

14. Question: Why Do I Get “ORA-24327”?

Answer: This error generally means that the environment ORACLE_HOME is not set or is set incorrectly or the D_LIBRARY_PATH or PATH does not include the right dynamic link libraries. It can also indicate a mismatch when trying to use weblogic.jdbc.oci.Driver with an earlier or later version of the Oracle client software than is supported. In that case, try to use the Oracle Thin driver instead. (E learning portal)

15. Question: Why Do I Get “ORA-00600”?

Answer: This error generally means that the version of the Oracle server is newer than version of the driver you are using. In case you are using the Oracle thin driver, you will need to download the latest ojdbc14. jar from Oracle and put it at the beginning of your CLASSPATH (and possibly update any scripts that start the server, such as startweblogic.cmd, since they override the CLASSPATH).