WEBLOGIC SERVER FAQ(ANS)--10

weblogic interview questions and answers

141.What is JNDI?

JNDI (Java Naming and Directory Interface) is a Java EE lookup service that maps names to services and resources. JNDI provides a directory of advertised resources that exist on a particular stand-alone (unclustered) WebLogic server, or within a WebLogic server cluster. Examples of such resources include JMS connection factories, JMS destinations, JDBC (database) data sources, and application EJBs. 
A client connecting to any WebLogic server in a WebLogic cluster can transparently reference any JNDI advertised service or resource hosted on any WebLogic server within the cluster. The client doesn't require explicit knowledge of which particular WebLogic server in the cluster hosts a desired resource.

142.What is a JMS connection factory?

A JMS connection factory is a named entity resource stored in JNDI. Applications, message driven beans (MDBs), and messaging bridges lookup a JMS connection factory in JNDI and use it to create JMS connections. JMS connections are used in turn to create JMS sessions, producers, and consumers that can send or receive messages.

143.What is a JMS connection-id?

JMS connection-ids are used to name JMS client connections. Durable subscribers require named connections, otherwise connections are typically unnamed. Note that within a clustered set of servers or stand-alone server, only one JMS client connection may use a particular named connection at a time. An attempt to create new connection with the same name as an existing connection will fail.

144.What is the difference between a JMS topic and a JMS queue?

JMS queues deliver a message to one consumer, while JMS topics deliver a copy of each message to each consumer.

145.What is a non-durable topic subscriber?

A non-durable subscriber creates unnamed subscriptions that exist only for the life of the JMS client. Messages in a non-durable subscription are never persisted—even when the message's publisher specifies a persistent quality of service (QOS). Shutting down a JMS server terminates all non-durable subscriptions.

146.What is a durable subscriber?

A durable subscriber creates named subscriptions that continue to exist even after the durable subscriber exits or the server reboots. A durable subscriber connects to its subscription by specifying topic-name, connection-id, and subscriber-id. Together, the connection-id and subscriber-id uniquely name the subscriber’s subscription within a cluster. A copy of each persistent message published to a topic is persisted to each of the topic's durable subscriptions. In the event of a server crash and restart, durable subscriptions and their unconsumed persistent messages are recovered.

147.What is the WebLogic Store-and-Forward Service?

The WebLogic Store-and-Forward (SAF) Service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. For example, with the SAF service, an application that runs on or connects to a local WebLogic Server instance can reliably send messages to a destination that resides on a remote server. If the destination is not available at the moment the messages are sent, either because of network problems or system failures, then the messages are saved on a local server instance, and are forwarded to the remote destination once it becomes available.

148.When should I use the WebLogic Store-and-Forward Service?

The WebLogic Store-and-Forward (SAF) Service should be used when forwarding JMS messages between WebLogic Server 9.0 or later domains. The SAF service can deliver messages:

• Between two stand-alone server instances.
• Between server instances in a cluster.
• Across two clusters in a domain.
• Across separate domains.

149.What is a messaging bridge?

Messaging bridges are administratively configured services that run on a WebLogic server. They automatically forward messages from a configured source JMS destination to a configured target JMS destination. These destinations can be on different servers than the bridge and can even be foreign (non-WebLogic) destinations. Each bridge destination is configured using the four common properties of a remote provider:

• The initial context factory.
• The connection URL.
• The connection factory JNDI name.
• The destination JNDI name.

Messaging bridges can be configured to use transactions to ensure exactly-once message forwarding from any XA capable (global transaction capable) JMS provider to another.

150.When should I use a messaging bridge?

Typically, messaging bridges are used to provide store-and-forward high availability design requirements. A messaging bridge is configured to consume from a sender's local destination and forward it to the sender's actual target remote destination. This provides high availability because the sender is still able to send messages to its local destination even when the target remote destination is unreachable. When a remote destination is not reachable, the local destination automatically begins to store messages until the bridge is able to forward them to the target destination when the target becomes available again.

151.When should I avoid using a messaging bridge?

Other methods are preferred in the following situations:

• Receiving from a remote destination—use a message driven EJB or implement a client consumer directly.
• Sending messages to a local destination—send directly to the local destination.
• Environment with low tolerance for message latency. Messaging Bridges increase latency and may lower throughput. Messaging bridges increase latency for messages as they introduce an extra destination in the message path and may lower throughput because they forward messages using a single thread.
• Forward messages between WebLogic 9.0 domains—Use WebLogic Store-and-Forward.

152.How many types of JMS stores are available?

• The JMS store can be configured to use either:
• A file store
• A JDBC store (a connection pool)

153.How will you configure a JMS JDBC Store?

• To configure JMS JDBC persistence, perform the following:
• Create a JDBC DataSource.
• Create a JMS store and refer to the JDBC DataSource.
• Refer to the JMS store from the JMS server configuration.
• The required infrastructure (tables and so on) is created automatically.

154.What Is a Transaction?

• A transaction is a mechanism to handle groups of operations as though they were one.
• Either all operations in a transaction occur or none occur 
  at all.
• The operations involved in a transaction might rely on multiple servers and databases.

155.How many Types of Transactions are there? Explain?

• A local transaction deals with a single resource manager. Local transactions use the non-Extended Architecture (non-XA) interface between Oracle WebLogic Server and the resource manager.
• A distributed transaction coordinates or spans multiple resource managers.
• Global transactions can deal with multiple resource managers. Global transactions use the Extended Architecture (XA) interface between Oracle WebLogic Server and the resource managers.
• You need to create non-XA or XA resources for local transactions. However, for global transactions, you need to create only XA resources.

156.Explain about Two-Phase Commit Protocol?

• The Two-Phase Commit (2PC) protocol uses two steps to commit changes within a distributed transaction.
• Phase 1 asks the RMs to prepare to make the changes.
• Phase 2 asks the RMs to commit and make the changes permanent or to roll back the entire transaction.
• A global transaction ID (XID) is used to track all the changes associated with a distributed transaction.

157.Explain about Extended Architecture Protocol (XA)?

The Extended Architecture (XA) protocol:

• Is the interface that is used between WLS and the RMs
• Implements the 2PC protocol
• Allows programs to control the RMs that are involved in distributed transactions

158.What is the user of “Transaction Log”?

• Each server has a transaction log that stores information about committed transactions coordinated by the server that may not have been completed.
• Oracle WebLogic Server uses the transaction log when recovering from system crashes or network failures.
• You cannot directly view the transaction log because the records are in a binary format and are stored in the default persistent store for the server.

159.Explain about Logging Last Resource?

• You can configure a JDBC data source to enable the Logging Last Resource (LLR) transaction optimization, which:
• Enables one non-XA resource to participate in a global transaction
• Has improved performance and the same ACID guarantee as XA
• The LLR optimization improves performance by:
• Removing the need for an XA JDBC driver to connect to the database. XA JDBC drivers are typically inefficient compared to non-XA JDBC drivers.
• Reducing the number of processing steps to complete the transaction, which also reduces network traffic and I/O
• Removing the need for XA processing at the database level (if the database is the one non-XA resource)

160.What Is LDAP? 

The Lightweight Directory Access Protocol:

• Is derived from X.500
• Provides a hierarchical lookup service
• Supports sophisticated searching
• Can be secured via SSL