BEA Weblogic Interview Questions and Answers

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

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.

Is This Answer Correct?    0 Yes 1 No

27 :: Does WebLogic JMS support clustering?

WebLogic JMS supports cluster-wide, transparent access to destinations from any server in the cluster. A system administrator can establish cluster-wide, transparent access to destinations from any server in the cluster by configuring multiple connection factories and using targets to assign them to WebLogic Servers. Each connection factory can be deployed on multiple WebLogic Servers.

The application uses the Java Naming and Directory Interface (JNDI) to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for a set of destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate server.

You can configure multiple JMS servers on the various nodes in the cluster as long as you give them different names. You can assign destinations to the various JMS servers.

One problem to be aware of is the propagation delay in replicating entries in JNDI. If you have an MDB deployed on one node but reference a destination on another node, the deployment may fail with a javax.naming.NamingException exception. The problem occurs because the server is not synced up to the JNDI from the remote server (JMS server) yet, so the JNDI lookup of destination as part of MDB deployment will fail. One workaround is for each MDB to reference a local destination. Another approach is deploy the MDBs after the server boots (plus a delay for JNDI propagation). To get around losing messages before the MDB is deployed, use durable subscribers. This problem is fixed for MDBs in WLS 6.1, where the MDB will be deployed and reconnection will be retried until the destination is available. Note that this is still a problem for EJBs in general that try to reference a non-local JMS destination.

Is This Answer Correct?    0 Yes 0 No

28 :: Which of the following statements are true regarding the identity of two EJBs?

a. Two stateful session beans are identical if their data attributes are identical.
b. Two stateful session beans are identical if their session contexts are equal.
c. Two stateless session beans are identical if they are of the same type.
d. Two stateless session beans are identical if their session contexts are equal.
e. Two entity beans are identical if they have same primary key but different home interface.
f. Two entity beans are identical if they have different primary key but same home interface.


B and C are correct. Since the stateful session beans maintain the conversational state of the clients, they are identical when their session contexts are equal. Two stateful session beans may have identical data attributes, but if the session contexts are different they are not identical. Thus choice A is incorrect and B is correct. Since stateless beans do not retain the conversational state, they are considered identical if they are of the same type. Thus choice C is correct.
If two entity objects have the same home interface and primary key, they are considered identical. The EJB specification does not mention object equality based on the = = operator. Also, if you compare two object references using the Java API, Object.equals(Object obj), the result is unspecified. The only way to compare object equality is through the isIdentical (EJBObject) API. Thus choice E and F are incorrect.

Is This Answer Correct?    0 Yes 0 No

29 :: In the WebLogic server, if stateless session bean instances are getting frequently created and removed, performance can improved by setting a high value for which of the following?

a. max-beans-in-free-pool
b. max-beans-in-cache
c. max-beans-in-memory
d. max-stateless-beans-in-cache


Choice A is correct. WebLogic Server maintains a free pool of EJBs for every stateless session bean class. The max-beans-in-free-pool element defines the size of this pool. By default, max-beans-in-free-pool has no limit; the maximum number of beans in the free pool is limited only by the available memory.
When EJBs are created, the session bean instance is created and given an identity. When the client removes a bean, the bean instance is placed in the free pool. When you create a subsequent bean, you can avoid object allocation by reusing the previous instance that is in the free pool. So the max-beans-in-free-pool element can improve performance if EJBs are frequently created and removed. Keeping this parameter too high uses extra memory and keeping it too low causes unnecessary object creation.
WebLogic Server allows you to configure the number of active beans that are present in the EJB cache (the in-memory space where beans exist). The max-beans-in-cache element specifies the maximum number of objects of this class that are allowed in memory. When max-bean-in-cache is reached, WebLogic Server passivates some EJBs that have not been recently used by a client. Choices C and D are not valid properties.

Is This Answer Correct?    0 Yes 0 No

30 :: What happens if acknowledge() is called within a transaction?

As per the JMS specification, when you are in a transaction, the acknowledgeMode is ignored. If acknowledge() is called within a transaction, it is ignored.

Is This Answer Correct?    0 Yes 0 No