Oracle Weblogic Tutorial for Beginners

Oracle Weblogic Tutorial for Beginners from svr technologies by 12+ years experienced faculty. 30+ Tutorial videos & 100+ interview questions and answers.

Weblogic Tutorial Videos

You, Will, Learn in Oracle Weblogic Tutorial

1. Question: What is the Difference Between the Compatibility Realm and MyRealm Under What Circumstances Should I Use Each of These Realms?

Answer: If you have a 6.x config.xml file and you boot WebLogic Server, the following realms are created:

Compatibility realm—Allows you to use an existing 6.x security configuration as is in the management environment provided in this release of WebLogic Server. (Weblogic Training)
The Realm Adapter providers allow access to existing stores of users, groups, and access control lists (ACLs). (Interview Questions and Answers)
my realm—Is the default security realm in this release of WebLogic Server. By default, the WebLogic Security providers are configured in my realm.

2. Question: How Do I Deserialize an httpsSession?

Answer: To deserialize an HTTP session, construct a utility class that uses the current thread’s context classloader to load the user-defined objects within the application context.  then add this utility class to the system CLASSPATH.

3. Question: How Do I Call a Servlet With Parameters in the URL?

Answer: The usual format of a servlet parameter is a name=value pair that comes after a question-mark (?) at the end of the URL. To access these parameters, call the getParameter() method on the HttpServletRequest object, then write code to test the strings. For example, if your URL parameters are “func=topic,” where your URL appears as (How Do I Call a Servlet With Parameters in the URL)
https://en.wikipedia.org/wiki/Web_hosting_service servlet?func=topic..

then you could parse the parameter as follows, where “req” is the HttpServletRequest object:

String func = req.getParameter(“func”);
if (func.equalsIgnoreCase(“topic”)) {

4. Question: How Do an RMI-IIOP Application and an Existing CORBA Object Interoperate?

Answer: If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI-IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces. 

For example, to interoperate between an RMI-IIOP client and a C++ object you need to:

  1. Define the remote interface of the object in Java as an RMI interface.
  2. Run rmic -idl against the interface to produce IDL compatible with the RMI interface.
  3. Run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object. 

5. Question: Why Do I Get “NoClassDefFound”/”Too Many Open Files” Messages On Solaris?

Answer: We have seen this situation when the user account runs out of file descriptors. On Solaris, each user account has a certain limited number of file descriptors. You can find out how many file descriptors you have with the limit command in csh.

You can increase file descriptors if you have enough privileges with the ulimit command in the csh. Otherwise, ask your system administrator to increase the file descriptors available to your processes.

6. Question: What Affects Servlet Performance Besides Clients and Traffic?

Answer: Response time for a servlet is about 5 times slower when you are running a screen saver on the machine, particularly for the OpenGL screen savers. Try turning off your screen saver and see if that helps!

7. Question: How Do I Speed Up HTTP Tunneling?

Answer: Unfortunately, a significant performance hit occurs when you use HTTP tunneling. We have optimized it somewhat, but, because everything is encapsulated in HTTP, HTTP tunneling is slower than direct Java-to-Java TCP/IP connections. 

Be sure that you really need to use HTTP tunneling. For example, if your firewall can pass IP packets through port 80, you can use the fast T3 protocol on port 80.

8. Question: What Changed in the 6.1 Plug-in?

Answer: The following changed: 

    • HTTP1.1 support — chunk-transferred and keep-alive (except for apache1.3.x)
    • Session parsing (this breaks the backward compatibility) 
  • SSL support from the plug-in to WebLogic Server 

9. Question: How Does the Plug-in Route the Request For a Sticky Session?

Answer: If the browser sends a cookie, we look for “JSESSIONID” (configurable by a parameter called “CookieName”) in the “Cookie: ” header.

If the cookie is disabled and URL re-writing is used, the session id is encoded in the URL. In WebLogic Server 5.1 and earlier, it was encoded in the query string: 

?WebLogicSession=my_dumy_session

In WebLogic Server 6.0 and later, it was encoded in the parameter:

;JSESSIONID=my_dummy_session

If no session is found in the query string or parameter and if it is small enough to be read into memory, WebLogic Server looks for the session in the post data.

10. Question: I Get the Following XAER_RMFAIL XAException When Accessing an XAResource: “Internal Error: XAResource ” is Unavailable”. What Does That Mean How Should I Handle It?

Answer: JTA has its own resource health monitoring that works as follows: 

A resource is considered active either if there are no pending requests or if we get a result from any of the XAResource pending requests that are not a XAER_RMFAIL. If an XAResource is not active within the two minutes, it is declared dead. Any further requests to the XAResource are shunned, and a XAER_RMFAIL XAException as above is thrown. The intent is to prevent further loss of threads if the RM is dead.

A resource is declared active again if you re-register the XAResource with the WebLogic Server Transaction Manager by calling weblogic.transaction.TransactionManager.unregisterResource followed by registerStaticResource or registerDynamicResource, or after a timeout period of 30 minutes. If you are using WLS JDBC connection pools, you only need to enable the JDBC connection pool refresh feature (by specifying the “RefreshMinutes” property of the connection pool), and, upon a successful connection pool refresh, the corresponding XAResource will be re-registered automatically. If you are registering your own XAResource, either via weblogic.transaction.TransactionManager.registerStaticResource or registerDynamicResource APIs, you will need to re-register the XAResource by calling weblogic.transaction.TransactionManager.unregisterResource followed by registerStaticResource or registerDynamicResource.

In general, a good way to debug potential RM problems is to turn on JTA XA debugging, by specifying -Dweblogic.Debug=weblogic.JAXA as JVM parameter on WLS startup. 

11. Question: Can I Close a JDBC Connection After the Distributed Transaction is Committed or Rolled Back?

Answer: For both non-XA and XA driver, you can close the connection after the distributed transaction is completed. 

12. Question: Can I Obtain a JDBC Connection Before I Start a Distributed Transaction?

Answer: This depends on whether you are using a non-XA or XA driver. 

  • When you use a non-XA driver in a distributed transaction, always obtain a JDBC connection after the distributed transaction is begun.
  • If you are using an XA driver, you can obtain the connection before or after the distributed transaction begins. 

13. Question: Can I Use a Non-XA Driver in Distributed Transactions?

Answer: When the non-XA connection pool is the only resource participating in a transaction distributed across multiple servers, you just need to configure a TxDataSource for the non-XA driver.

However, when more than one resource participates in the distributed transaction, you must also set the TxDataSource property EnableTwoPhaseCommit=true. For more information, see Configuring JDBC DataSources in the Administration Console Online Help. In both cases, always obtain a connection via the DataSource interface, not through the deprecated DriverManager interface. If you obtain a connection via DriverManager, the interface cannot pick up the EnableTwoPhaseCommit setting of the TxDataSource; this may result in unexpected behavior in distributed transactions. Also, when you use the DataSource interface, you do not need to distinguish either the URL or the specific WebLogic multitier driver (JTS, RMI, or pool.) The URL and specific driver are obtained through the config.xml file and JNDI lookup.

14. Question: Why Does the Messaging Bridge Sometimes Hang While Processing Messages?

Answer: By default, the AllowCloseInOnMessage attribute in the JMSConnectionFactory class is set to false. To ensure that the server does not hang, set this value to true. 

15. Question: How Do I Enable Debugging For the Messaging Bridge?

Answer: 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):

-WebLogic.Debug.DebugMessagingBridgeStartup=true
-WebLogic.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 shown above. For example:

WebLogic.Debug.DebugMessagingBridgeStartupDumpToConsole=true

16. Question: When Configuring a Source or Target Messaging Bridge Destination, Do I Need to Set the Adapter Classpath Field?

Answer: Leave the Adapter Classpath field blank when connecting to source and target destinations that are both running on release 8.1. When connecting to either a source or target destination that is running on release 6.0 or earlier, the Adapter Classpath field must indicate the location of the classes for the earlier WebLogic Server release. When connecting to a third-party JMS provider, the bridge destination must supply the provider’s CLASSPATH in the WebLogic Server CLASSPATH. (Best Online training institute)

17. Question: 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 checkbox on the Messaging Bridge —> Configuration —> General administration console page. 

18. Question: 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?

Answer: 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\server\lib directory. For the Exactly-once QOS, the transaction adapter, jms-xa-adp.rar, must be deployed in the release 8.1 domain where the bridge is running, via the select Deployments —> Connector 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. 

19. Question: 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 console page have been properly completed:

    • Connection URL—this must be the URL of the JNDI provider used to look up the connection factory and actual destination.
    • Destination JNDI Name—this must be the JNDI name of the actual destination mapped to the source bridge destination.
  • 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.
  • 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:

  • Is the WebLogic Server instance hosting the source-destination running?
  • 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.

20. Question: Do I Need a 2PC Licence When I Use JMS With One JDBC Non-XA Driver?

Answer: Yes, you do. JMS is also an XAResource that participates in the distributed transaction. Therefore, there are two resources participating in the distributed transaction, and a 2PC license is needed.

21. Question: Why Do I Get SQLException “ResultSet Already Closed” Message?

Answer: WebLogic driver for Oracle has a limitation that closes all open result sets when the method returns to the caller.

Using the driver from the server-side, for example, in a bean, does not have this limitation. Using the driver from the server side is also recommended from application architecture and performance perspective. Using the driver from the client-side incurs round-trip cost for every JDBC call being made.

This limitation exists because WebLogic driver for Oracle XA is implemented using Oracle’s OCI API and C XA switch, and there is an Oracle problem when using OCI with XA in multi-threaded mode. Closing an OCI cursor in a thread that is different from the thread in which it is opened may result in a server crash or unexpected behavior. As a result, the WebLogic driver implicitly closes all open result sets upon returning a call to the caller.

22. Question: Can I Use More Than One Non-XA Connection Pool in Distributed Transactions?

Answer: No. Even if you set EnableTwoPhaseCommit=true for both TxDataSources of the connection pools, attempting to use two non-XA connection pools in the same distributed transaction will result in 

“java.sql.SQLException: Connection has already been created in this tx context for the pool named.  Illegal attempt to create a connection from another pool: “

when you attempt to get the connection from the second non-XA connection pool.

23. Question: How Do Server Session Pools and Message Driven Beans Compare?

Answer: For a detailed discussion on this topic, see the “MDBs vs. Server SessionPools” section in the “WebLogic JMS Performance Guide” white paper (WeblogicJMS Performance Guide.zip) on the BEA dev2dev website. 

24. Question: How Do I Roll Back a Transaction Within an MDB?

Answer: To roll back 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();

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();
Weblogic Training with these facilities:

25. Question: Can You Use a Foreign JMS Provider to Drive an MDB Transactionally?

Answer: Yes. In WebLogic Server 7.0 or later, you can deploy an MDB that supports container-managed transactions against a foreign JMS provider. If the MDB is configured with a “transaction-type” attribute of “Container” and a “trans-attribute” of “Required”, then WLS will use XA to automatically enlist the foreign JMS provider in a transaction. 

If the foreign JMS provider does not support XA, then you cannot deploy an MDB that supports container-managed transactions with that provider. Furthermore, if the JMS provider does support XA, you must ensure that the JMS connection factory that you specify in the WebLogic-EJB-jar.xml file supports XA—each JMS provider has a different way to specify this.

26. Question: If an MDB Uses a Durable Subscription, Will Messages Be Accumulated If the MDB is Not Deployed?

Answer: The durable subscription is created when the MDB is deployed for the first time. The durable subscription is not deleted when the MDB is undeployed or deleted. This means that once the MDB has been deployed once, messages will continue to accumulate on the subscription, even if the MDB is undeployed or deleted. So, when an MDB is retired from service, you should delete the durable subscription to prevent a build-up of messages. 

You can use the administration console to do this, or you can write a standalone program using the Java API that calls unsubscribe on the durable subscription.

27. Question: Can an MDB Be a Message Producer or Both a Producer and Consumer?

Answer: Yes. You have no JMS context inside the MDB so you will need to establish a connection, session, and producer yourself. One option is to do this every time you come into the onMessage routine for the MDB. This is sufficient if the message rate is relatively low. The second option is to establish the necessary objects in ejbActivate(). Note that the objects are not serializable so they can’t be passivated for a stateful session bean or an entity bean. When the EJB deactivates, you need to close the associated objects. The third option is that you could build up a JMS connection/sender session pool within a startup class complete with your own synchronization and blocking to get a connection. 

28. Question: How Does Concurrency Work For Message-Driven Beans?

Answer: For a queue, multiple JMS Sessions are created on each server instance where the MDB is deployed. The number of sessions created is never greater than the max-beans-in-free-pool setting in the MDB’s deployment descriptor. JMS then delivers messages in parallel to the MDB instances as it would for any other kind of message listener. If an MDB is deployed to multiple servers in a cluster, Sessions are created for each MDB instance on each server. 

For a topic, however, one topic consumer is used to pass out messages to multiple threads to get concurrency, while producing only a single copy of each message. If multiple MDBs are deployed to listen on the same topic, then each MDB will receive a copy of every message. Therefore, when an MDB is deployed to multiple servers and it listens to a topic, each server will receive its own copy of each message. So, if you want a message to be processed by exactly one MDB, you should use a queue. 

29. Question: How Can I Avoid Asynchronous Message Deadlocks?

Answer: Due to a limitation in the JMS 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: (How Can I Avoid Asynchronous Message Deadlocks)

public class CloseTest() {
private void xxx() {
synchronized (this) {
create connection/session/consumer
initialize and set a listener for this consumer;
wait();
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 closest 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. 

30. Question: Is There a Way to Dynamically Change an Existing Selector For a TopicConsumer Using the SetMessageSelecter(String)?

Answer: No. Once you instantiate the consumer the selector is fixed at the time that the consumer is created. Changing the selector  is like removing the current consumer, removing all associated messages and then creating a new one. 

31. Question: How Should Connections and Sessions Be Allocated?

Answer: Think of a connection as a single physical connection (a TCP/IP link). A session is a means for producing and consuming an ordered set of messages. Creating a connection is generally expensive. Creating a session is less expensive. Generally, people use one connection and share across all the threads with each thread having its own session. If you have thread groups and need to start/stop/close the resources for a given group, one connection per group is good. A group can have exactly one thread. 

32. Question: What Can I Do When I Get java.lang.OutOfMemoryError Because Producers are Faster Than Consumers?

Answer: Quotas can be used to help this situation. Your sender will then receive ResourceAllocationExceptions and the server will stay up. In release 8.1 or later, senders can be configured to block waiting for space rather than receive Resource Allocation Exceptions.

You can also use the Message Paging feature, which saves memory by swapping messages out from virtual memory to a dedicate paging store when message loads reach a specified threshold. JMS message paging saves memory for both persistent and non-persistent messages, as even persistent messages cache their data in memory.

33. Question: Is It Okay to Add New Sessions and Subscribers to a Queue or Topic Connection Once It Has Been Started?

Answer: 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 Specification. 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 session that is part of a started connection. However, 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 about 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.

34. Question: What Should an XPATH Selector Look Like?

Answer: The following is an example of an XPATH selector. Pay careful attention to the use of double and single quotes.

String selector =
“JMS_BEA_SELECT(‘xpath’, ‘/recipient/transport/text()’) =
’email’”;
tsubscriber = tsession.createSubscriber(topic, selector, false);

JMS_BEA_SELECT is a built-in function in WebLogic Server JMS SQL syntax. You put it in your selector string when you create a consumer. Note the use of single quotes around xpath, the XML tab, and the string value. 

35. Question: What is the Standard Way to Create Threads, Do Initialization, etc. Within the Application Server?

Answer: Threads should generally not be created by the user directly is because things may not work correctly. User-created threads do not have some of the thread-local variables pre-set by WebLogic when it creates it’s own execute threads, the associated transaction context, or the environment such as the proper class loader. The WebLogic-specific way of doing this is with a startup class or using WebLogic Time Services. The portable way to do this is to define a load-on-startup servlet, doing the initialization in the init() method and the cleanup in the destroy() method. The servlet itself does nothing. This approach also allows for undeploy/redeploy of the application without restarting the server, including proper  cleanup/initialization each time. It also providers more dynamic management of the dependent classes without restarting the server. 

36. Question: Is It Possible to Send or Receive a Message From Within a Message Listener?

Answer: Yes. You can send to or receive from any queue or topic from within in a message listener. 

Outside of an MDB, you can do this by using the same Connection or Session that the onMessage() is part of. When you create your message listener, you pass a session into your constructor.  Then you have access to the session in your onMessage() method and are able to make synchronous – not asynchronous – calls from within the onMessage() method. Do not use another Session that is servicing another onMessage(), because that would multi-thread the Session, and Sessions do not support multi-threading.

However, when using this technique outside an MDB, there is no way to guarantee that the receipt of the message by the MessageListener, and the end of the new message, happen as part of the same transaction. So, there can be duplicates or even lost messages. For example:

  • If you call acknowledge after the publish() and the acknowledge fails for whatever reason (network or server failure), then you will see the message again and will end up publishing twice (possible duplicate semantics). You can try to keep track of sequence numbers to detect duplicates, but this is not easy.
  • If you call acknowledge before the publish(), you get at-most-once transaction semantics. If the publish() fails, you don’t know if the failure occurred before or after the message reached the server.

If you require exactly-once transactional semantics using onMessage(), then you must use transactional MDBs. In this case, the onMessage() method for a transactional MDB starts the transaction and includes the WebLogic JMS message received within that transaction. Then, you must ensure that the send or publish of the new message is part of the same transaction as the receipt of the message. In WebLogic Server 8.1, you can guarantee that this happens by using a connection factory that you get from a resource-reference defined for the MDB. For detail instructions on how to accomplish this, see “Using JMS With EJBs and Servlets” in Programming WebLogic JMS. By using a resource-reference, you also get automatic pooling of the JMS Connection, Session, and MessageProducer objects, and the transaction enlistment will happen automatically regardless of whether you use WebLogic JMS or another JMS provider, as long as the JMS provider supports XA.

In earlier versions of the product, WebLogic JMS would automatically enlist itself with the current transaction if the UserTransactionsEnabled or XAServerEnabled flag was set on the connection factory. However, prior to release 8.1, the server will not pool any JMS objects or automatically enlist a foreign JMS provider in the transaction. In these earlier versions, you may want to cache JMS objects yourself. 

37. Question: How Do I Issue the Close() Method Within an OnMessage() Method Call and What are the Semantics of the Close() Method?

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

The session or connection 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).
  • It 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 for the received message, ‘s acknowledge() method. Closing a closed connection does not affect. 

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. 

38. Question: When Should I Use Server Session Pools and Connection Consumers?

Answer: WebLogic JMS implements an optional JMS facility for defining a server-managed pool of server sessions. However, session pools are now used rarely, as they are not a required part of the J2EE specification, do not support JTA user transactions, and are largely superseded by message-driven beans (MDBs), which are simpler, easier to manage, and more capable.

For a detailed discussion on this topic, see the “MDBs vs.ServerSessionPools” section in the “WebLogic JMS Performance Guide” white paper.

39. Question: What is the NO_ACKNOWLEDGE Acknowledge Mode Used For?

Answer: The NO_ACKNOWLEDGE acknowledge mode indicates that received messages do not need to be specifically acknowledged which improves performance, but risks that messages are lost. This mode is supported for applications that do not require the quality of service provided by session acknowledge and that do not want to incur the associated overhead. Messages sent to a NO_ACKNOWLEDGE session are immediately deleted from the server. Messages received in this mode are not recovered and, as a result, messages may be lost and/or duplicate messages may be delivered if an initial attempt to deliver a message fails.

Note: You should avoid using this mode if your application cannot handle lost or duplicate messages. Duplicate messages may be sent if an initial attempt to deliver a message fails. 

In addition, we do not recommend that this acknowledge mode be used with persistent messaging, as it implies a quality of service that may be too low for persistent messaging to be useful.

40. Question: What Precautions Should I Take When I Use Blocking Receive() Calls?

Answer: 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, which 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: The 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.

41. Question: How Should I Use Blocking and Asynchronous Receive() Calls

Answer: The synchronous receive() method blocks until a message is produced, the timeout value, if specified, elapses or the application is closed. We strongly recommend that you avoid using blocking receive() calls on the server-side because a synchronous receive() call consumes resources for the entire duration that the call is blocked.

When methods are received asynchronously, the application is notified using a message listener only when a message has been produced, so no resources are consumed waiting for a message. 

42. Question: How Should an Application Be Set Up to Subscribe to Multiple Topics?

Answer: If you want to listen to N topics, using N subscribers and N sessions gives you concurrency up to N simultaneous threads of execution provided you have that many threads to work with. N subscribers and 1 session serializes all subscribers through that one session. If the load is heavy they may not be able to keep up without the extra threads.(Company) Also, if you are using CLIENT_ACKNOWLEDGE, N sessions gives you N separate message streams that can be individually recovered. Having 1 session crosses the streams giving you less control.

As of version 6.x or later, WebLogic JMS on the server side efficiently uses a small, fixed number of threads independent of how many client sessions there are.

43. Question: Why Doesn’t Set Values Work Using javax.jms.Message.setJMSPriority, DeliveryMode, Destination, TimeStamp or Expiration?

Answer: These methods are for vendor use only. The message values are overwritten on each send/publish. You should use the equivalent methods on the MessageProducer, QueueSender, or TopicPublisher to set these values (i.e., setJMSPriority, setDeliveryMode, setTimeToLive). 

Check to see that these values are not being overridden by the optional template configuration override values. 

44. Question: Is There a Way to Make a Queue Such That If One Application Has One Object as Listener On That Queue, No Other Application Can Listen to the Messages On That Queue?

Answer: No. An alternative is to create a topic with a single durable subscription because a durable subscription may only have one consumer associated with it. The only drawback is that selectors would no longer work the same as they do with queues. Changing the selector on a durable subscription “resets” the subscription as per Sun Microsystems’ JMS specification, causing all messages currently in the subscription to be deleted. 

45. Question: Is It Possible to Have Multiple Queue Receivers Listening on the Same Queue?

Answer: Yes, although the JMS specification does not define the behavior here.

46. Question: How Do I Ensure Message Ordering Even in the Event of Rollbacks and Recoveries?

Answer: In WebLogic JMS 8.1 message ordering can be maintained to single consumers on a queue or topic subscription – even in the event of rollbacks and recoveries, as described in “Ordered Redelivery of Messages” in Programming WebLogic JMS.

47. Question: In What Order are Messages Delivered to a Consumer?

Answer: Order is maintained between any producer and consumer for like delivery mode, sort order, and selector in the absence of a rollback or recover. There are no guarantees of order when multiple producers send to a single consumer or multiple consumers receive from multiple producers. 

Order is generally maintained between a producer and a consumer. However, non-persistent messages can get ahead of persistent messages of higher sort order (i.e., higher priority), can move ahead of each other and recover or rollback puts messages that were already received back into the queue/topic, which affects the order.

Most messaging systems (including WebLogic JMS) maintain order between a producer and a destination and then order between the destination and the consumer. So, once things arrive at the destination, the order does not change. Finally, the asynchronous pipeline that is supported in WebLogic JMS affects the ordering. By default, there can be as many as ten outstanding messages pushed out from the server to an asynchronous client that has not been seen by the client yet.  If the asynchronous consumer is “caught” up, these messages will not be sorted. Destination sorting does not occur in the pipeline. If a destination is sorted by priority, and a new message comes in of higher priority than those messages already in the pipeline, it will not leap ahead in the pipeline, it will become first in the destination. The size of the pipeline is configurable; see the MessagesMaximum setting on the connection factory used. If you want real priority sorting, change the maximum number of messages on the factory to one. 

48. Question: Do Client Identifiers Need to Be Unique?

Answer: Using durable subscribers, if subscribing from two different clients and using the same connection factory and the connection factory has a configured clientID, distinct clientID’s must be set for each after the Topic Connection has been created.  Each connection needs a unique client. If you configure a connection factory with a client, you can only create one TopicConnection with that factory until that one connection is closed.

49. Question: How Should I Use Sorted Queues or Topics?

Answer: Destinations are sorted as FIFO (first-in, first-out) by default; therefore, destination keys are used to define an alternate sort order for a specific destination. Destination keys can be message header or property fields. For a list of the valid message header and property fields, refer to the “Message” section in Programming WebLogic JMS.

Destinations can be sorted in ascending or descending order based on the destination key. A destination is considered to be FIFO if a destination key is defined as ascending for the JMSMessageID message header field, and LIFO (last-in, first-out) if defined as descending. The key defined for the JMSMessageID header field, if specified, must be the last key defined in the list of keys. You can define multiple destination keys to sort a destination.

To create a destination key, use the Destination Keys node in the Administration Console

50. Question: What Happens to a Message That is Rolled Back or Recovered?

Answer: When a message is rolled back or recovered, it is required. Where it goes in the queue is a function of the message relative to the sort order for the queue and the other messages in the queue.

In an unordered queue (most typical), the message would typically go at the head of the queue (since the queue is still sorted by arrival time – FIFO) unless some other message is being recovered at that same time, but still the sort order resolves any conflicts.

The message is redelivered to the first available consumer as soon as possible. If there are no consumers when it is required, then it would just sit there until there is one.

Starting in WLS 6.1, you can configure the maximum number of times that a message may be required. You can also specify a delay time before which the message will not be available after being requested. If a message reaches its maximum queue limit, it is put on an error destination if one is configured or silently dropped.

What is Oracle WebLogic Course?

The fundamental unit of Oracle WebLogic Administration Video Tutorials and management is the domain. A domain consists of a set of managed servers – Oracle WebLogic Server instances or processes that host applications – and an administration server that controls the configuration of all the servers within the domain. A domain contains one and only one administration server. A weblogic server administration video tutorials may comprise a single development server that combines administration server and managed server functions, or may comprise an administration server and many managed servers. Administration servers distribute Oracle WebLogic Tutorials information to managed servers, and protocols built on top of standard JMX are used to ensure reliable communication of configuration changes throughout the domain. There is no runtime requirement for the administration server to be available if the administration server is not available, applications deployed on managed servers will continue to provide application services uninterrupted. Managed servers running in these Oracle WebLogic Administration Video Tutorials may or may not be clustered. Oracle WebLogic Server clusters provide clients with a single logical view into applications that are distributed over multiple managed servers, and provide scalability and availability benefits for mission-critical applications.

Oracle WebLogic Course Overview

However, clusters also offer manageability benefits as well. Clustered servers are intended to be homogeneous or uniform – that is, they should run the same version of Oracle WebLogic Server, they should contain identical configurations with a few exceptions discussed in this Oracle WebLogic Administration Video Tutorials, and they should have the same applications deployed. Many management operations such as resource configuration and deployment can be targeted at clusters to improve management efficiency. The oracle weblogic video tutorial infrastructure ensures that deployment archives such as WARs, EARs, RARs and JARs are made available to managed server instances that will host the applications, and are prepared for application execution. In clustered configurations, Oracle WebLogic Administration Video Tutorials ensures that deployment is successfully completed on all servers within the cluster. Multiple staging modes for distributing deployment archives to managed servers are supported. Advanced deployment capabilities are also supported, such as production redeployment, which enables updates to application versions without interruption of application services to existing clients. The Oracle WebLogic Administration Video Tutorials is an optional component of the WebLogic Management Framework.

Job Opportunities on Oracle WebLogic

The node manager is a lightweight process designed to monitor and control server lifecycle operations, such as server startup and shutdown, for server instances on a given machine. The Oracle WebLogic Administration Video Tutorials for the node manager in previous releases was to share node manager instances across domains. In Oracle WebLogic Server 12.1.2, the default configuration is a node manager instance per domain on each managed server machine. The Oracle WebLogic Administration Video Tutorials can control the startup and shutdown of server instances through the node manager, and the node manager can be configured to perform certain operations like auto-restart of failed server instances. The weblogic tutorial for beginners video is a GUI and command-line tool for initial creation of Oracle WebLogic Server domains, and domains for Oracle Fusion Middleware products that are built on Oracle WebLogic Administration Video Tutorials. The Configuration Wizard creates domains based on templates. The related Domain Template Builder enables end-user creation of templates themselves such that once a domain configuration is created, it can be captured in a Configuration Wizard template for recreation of that domain on different machines.

SVR Features

These Oracle WebLogic Administration Video Tutorials provides an easy to use mechanism for initial domain creation, and a powerful capability for complex domain recreation and replication across cloud environments. Oracle WebLogic Suite 12.1.2 provides two consoles for managing Oracle WebLogic Server domains at runtime. The primary console used by Oracle WebLogic Server administrators is the oracle weblogic video training. The Administration Console is a Web Application that runs on the administration server. Oracle WebLogic Administration Video Tutorials provides full functionality for managing domain configuration, starting and stopping of servers, application deployment and monitoring of the domain environment. In addition Oracle WebLogic Suite 12.1.2 includes Oracle Fusion Middleware Control, which is the strategic console for management of individual Oracle Fusion Middleware product domains. The scope of Oracle WebLogic Server management functions provided in Fusion Middleware Control is not yet equivalent to that provided by the WebLogic Administration Console, but significant areas are covered, such as server monitoring, lifecycle management, application deployment, and common configuration requirements. The Oracle WebLogic Administration Video Tutorials are a Jython-based scripting environment that can be used to automate all aspects of Oracle WebLogic Server administration.

Conclusion

This is a popular tool for automating Oracle WebLogic Administration Video Tutorials permitting, for example, modification of “empty” domains using WLST scripts to replicate a desired configuration, or executing a uniform set of management tasks across multiple domains to achieve a consistent change in the configuration of all of the target domains. As mentioned in the prior section on development, WLST scripts can be created manually, or by recording actions taken in the oracle weblogic training videos, or by authoring scripts in Oracle Enterprise pack for Eclipse. WLDF is also engineered to work with two related features of the Oracle JDK – Java Mission Control and Java Flight Recorder. Java Flight Recorder is designed to retain, in a rolling in memory buffer, diagnostic information about server process execution over the past several minutes, including event data generated by WLDF. The Flight Recorder buffer can be persisted to disk at any time for post-incident analysis using the Java Mission Control GUI, enabling analysis of what was occurring in the server leading up to the incident in Oracle WebLogic Administration Video Tutorials.

Weblogic Videos

Duration: 20+ hours
5999/-
  • Experienced Faculty
  • Real-time Scenarios
  • Free Bundle Access
  • Course Next Version
  • Sample CV/Resume
  • Interview Q&A
Scroll to Top