Exercise 1

Question 6 :

An instance of stateful session EJB when accessed simultaneously from more than one clients on same VM results in RemoteException or EJBException. In case the client is a Servlet thread, which of the following techniques can be used to avoid RemoteException/EJBException?


A). Not possible.
B). Store the reference to the EJB instance as an instance variable of Servlet class.
C). Store the reference to the EJB instance as a local variable of Servlet class.
D). Make the Servlet client to be remote instead of internal to WebLogic server.
Answer : Option C

Explanation :

An instance of a stateful session EJB can be accessed from only one client virtual machine at a time. Multiple client threads from the same virtual machine can access the same instance of a stateful session EJB, but they must do so in a serial fashion. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client , if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. Thus choice D is incorrect. 
To avoid any exception, each Servlet should store a reference to a particular EJB instance in a local variable of the Servlet's service() method. Please note that variables local to methods like service(), doGet(), doPost() are not shared between different requests and are automatically thread safe. Thus choice C is correct. An instance variable unlike local variable is shared. Thus Choice B is incorrect. 
An implication of this rule is that an application cannot make loop back calls to a session bean instance. 
This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class.


Question 7 :

The Multicast TTL setting for a cluster in the WebLogic Admin console sets which of the following values?


A). Maximum time taken for multicast messages to reach their final destination
B). The number of routers a multicast message can pass through before the packet can be discarded
C). The multicast address to be used by the messages sent from the cluster
D). Minimum time taken for broadcasting a multicast message from the cluster
Answer : Option B

Explanation :

The Multicast TTL(TTL-Time to Live) setting specifies the number of routers a multicast message can pass through before the packet can be discarded. To configure the multicast TTL for a cluster, you should change the Multicast TTL value in the WebLogic Server administration console. This sets the number of network hops a multicast message makes before the packet can be discarded. 
If you choose to distribute a cluster over a WAN (or across multiple subnets), you must plan and configure your network topology to ensure that multicast messages are reliably transmitted to all servers in the cluster. One of the requirements to be met by the network is that the multicast Time To Live (TTL) value must be high enough to ensure that routers do not discard multicast packets before they reach their final destination.


Question 8 :

Which of the following algorithms is used by the WebLogic Server as the default load balancing strategy for clustered object stubs when no algorithm is specified ?


A). Round-robin
B). Weight-based
C). Random
D). None of the above
Answer : Option A

Explanation :

The basic idea behind load balancing is that by distributing the load proportionally among all the servers in the cluster, the servers can each run at full capacity. WebLogic Server clusters support several algorithms for load balancing clustered objects. The particular algorithm you choose is maintained within the replica-aware stub obtained for the clustered object. Configurable algorithms for load balancing clustered objects are: Round-robin, Weight-based and Random. 
WebLogic Server uses the round-robin algorithm as the default load balancing strategy for clustered object stubs when no algorithm is specified. Round-robin is the only load balancing strategy used by WebLogic proxy plug-ins for HTTP session state clustering. The round-robin algorithm cycles through a list of WebLogic Server instances in order. For clustered objects, the server list consists of WebLogic Server instances that host the clustered object. For proxy plug-ins, the list consists of all WebLogic Servers that host the clustered servlet or JSP.


Question 9 :

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.
Answer : Option B, Option C

Question 10 :

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
Answer : Option A

Explanation :

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.