Weblogic Interview questions -1

What is BEA Weblogic?
BEA WebLogic is a J2EE application server and also an HTTP web server by BEA Systems of San Jose, California, for Unix, Linux, Microsoft Windows, and other platforms. WebLogic supports Oracle, DB2, Microsoft SQL Server, and other JDBC-compliant databases. WebLogic Server supports WS-Security and is compliant with J2EE 1.3.
BEA WebLogic Server is part of the BEA WebLogic Platform™. The other parts of WebLogic Platform are:
* Portal, which includes Commerce Server and Personalization Server (which is built on a BEA-produced Rete rules engine),
* WebLogic Integration,
* WebLogic Workshop, an IDE for Java, and
* JRockit, a JVM for Intel CPUs.

WebLogic Server includes .NET interoperability and supports the following native integration capabilities:
* Native enterprise-grade JMS messaging
* J2EE Connector Architecture
* WebLogic/Tuxedo Connector
* COM+ Connectivity
* CORBA connectivity
* IBM WebSphere MQ connectivity

BEA WebLogic Server Process Edition also includes Business Process Management and Data Mapping functionality.
WebLogic supports security policies managed by Security Administrators. The BEA WebLogic Server Security Model includes:
* Separate application business logic from security code
* Complete scope of security coverage for all J2EE and non-J2EE components

Which of the following statements are true regarding MDBs (Message Driven Beans) on version 6.0 of WebLogic App Server?
a. MDBs support concurrent processing for both Topics and Queues.
b. MDBs support concurrent processing for only Topics.
c. MDBs support concurrent processing for only Queues.
d. MDBs support concurrent processing neither Topics nor Queues.
Choice A is correct. MDBs support concurrent processing for both Topics and Queues. Previously, only concurrent processing for Queues was supported. To ensure concurrency, change the weblogic-ejb-jar.xml deployment descriptor max-beans-in-free-pool setting to >1. If this element is set to more than one, the container will spawn as many threads as specified. WebLogic Server maintains a free pool of EJBs for every stateless session bean and message driven 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.

he two primary cluster services provided by WebLogic Server are?
a. Http Session State Clustering
b. File Service Clustering
c. Time Service Clustering
d. Object Clustering
e. Event Clustering
Choices A and D are correct. A WebLogic Server cluster is a group of servers that work together to provide a more scalable and reliable application platform than a single server. A clustered service is an API or interface that is available on multiple servers in the cluster. HTTP session state clustering and object clustering are the two primary cluster services that WebLogic Server provides. WebLogic Server also provides cluster support for JMS destinations and JDBC connections. WebLogic Server provides clustering support for servlets and JSPs by replicating the HTTP session state of clients that access clustered servlets and JSPs. To benefit from HTTP session state clustering, you must ensure that the session state is persistent, either by configure in-memory replication, file system persistence, or JDBC persistence. If an object is clustered, instances of the object are deployed on all WebLogic Servers in the cluster. The client has a choice about which instance of the object to call. This is Object Clustering. The APIs and internal services that cannot be clustered in WebLogic Server version6.0 are File services, Time services, WebLogic Events, Workspaces and ZAC.

How do stubs work in a WebLogic Server cluster?
Clients that connect to a WebLogic Server cluster and look up a clustered object obtain a replica-aware stub for the object. This stub contains the list of available server instances that host implementations of the object. The stub also contains the load balancing logic for distributing the load among its host servers.

What happens when a failure occurs and the stub cannot connect to a WebLogic Server instance?
When the failure occurs, the stub removes the failed server instance from its list. If there are no servers left in its list, the stub uses DNS again to find a running server and obtain a current list of running instances. Also, the stub periodically refreshes its list of available server instances in the cluster; this allows the stub to take advantage of new servers as they are added to the cluster.

Why did my JDBC code throw a rollback SQLException?
Your JDBC code may throw the following exception:
"The coordinator has rolled back the transaction.
No further JDBC access is allowed within this transaction."
The WebLogic JTS JDBC driver throws this exception when the current JDBC connection transaction rolls back prior to or during the JDBC call. This exception indicates that the transaction in which the JDBC connection was participating was rolled back at some point prior to or during the JDBC call.
The rollback may have happened in an earlier EJB invoke that was part of the transaction, or the rollback may have occurred because the transaction timed out. In either case, the transaction will be rolled back, the connection returned to the pool and the database resources released. In order to proceed, the JTS JDBC connection must be closed and reopened in a new transaction.

Must my bean-managed persistence mechanism use the WebLogic JTS driver?
Use the TxDataSource for bean-managed persistence.

Why is there no polymorphic-type response from a create() or find() method?
The EJB Specification prohibits this behavior, and the weblogic.ejbc compiler checks for this behavior and prohibits any polymorphic type of response from a create() or find() method.
The reason the create() and find() methods are not polymorphic is similar to the reason constructors are not polymorphic in Java. The derived classes generally do not know or cannot initialize the base class properly.

Must EJBs be homogeneously deployed across a cluster? Why?
Yes. Beginning with WebLogic Server version 6.0, EJBs must be homogeneously deployed across a cluster for the following reasons:
* To keep clustering EJBs simple
* To avoid cross server calls which results in more efficiency. If EJBs are not deployed on all servers, cross server calls are much more likely.
* To ensure that every EJB is available locally
* To ensure that all classes are loaded in an undeployable way
* Every server must have access to each EJB's classes so that it can be bound into the local JNDI tree. If only a subset of the servers deploys the bean, the other servers will have to load the bean's classes in their respective system classpaths which makes it impossible to undeploy the beans.

Which of the following are recommended practices to be performed in the ejbPassivate() method of a stateful session bean?
a. Close any open resources, like database connections
b. All non-transient, non-serializable fields(except some special types) should be set to null.
c. All transient fields should be set to null
d. Make all database connection reference fields transient
e. All primitive type fields should be set to null

Choices A, B and D are correct. When a bean is about to be passivated, its ejbPassivate() method is invoked, alerting the bean instance that it is about to enter the Passivated state. At this time, the bean instance should close any open resources and set all non transient, non serializable fields to null. This will prevent problems from occurring when the bean is serialized. Transient fields will simply be ignored.Serializable fields will be saved. Open resources such as sockets or JDBC connections must be closed whenever the bean is passivated. In stateful session beans, open resources will not be maintained for the life of the bean instance. When a stateful session bean is passivated, any open resource can cause problems with the activation mechanism.
A bean's conversational state may consist of only primitive values, objects that are serializable, and the following special types-SessionContext, EJBhome, EJBObject, UserTransaction and Context (only when it references the JNDI ENC) . The types in this list (and their subtypes) are handled specially by the passivation mechanism. They don't need to be serializable; they will be maintained through passivation and restored automatically to the bean instance when it is activated

While packaging the Web Application DefaultWebApp for deployment into the WebLogic server, the home and remote interfaces of the enterprise beans used by the servlets should reside in which directory?
a. DefaultWebApp/META_INF/classes
b. DefaultWebApp/META_INF/lib
c. DefaultWebApp/WEB_INF/lib
d. DefaultWebApp/WEB_INF/classes
e. DefaultWebApp/classes
Choice D is correct. When packaging a web application create META-INF and WEB-INF subdirectories in the application directory to hold deployment descriptors and compiled Java classes. All servlet classes and helper classes should reside in the WEB-INF/classes subdirectory. The home and remote interface classes for enterprise beans used by the servlets into the WEB-INF/classes subdirectory.
All the HTML files, JSP files, images, and any other files that these Web pages reference should exist in the application directory, maintaining the directory structure for referenced files. The META_INF directory contains the deployment descriptors for the enterprise beans, but not the classes.

How do I set up my CLASSPATH?
Setting up your CLASSPATH correctly depends on what you are trying to do. The most common tasks are described below:
* Starting WebLogic Server. See Setting the Classpath Option in the Starting and Stopping WebLogic Servers section of the Administration Guide. In addition, your WebLogic distribution includes shell scripts that you can use to start the server. These scripts, which are located in the domain directories under the config directory of your WebLogic Server distribution, automatically set up the CLASSPATH variable in the shell before starting the server.