Question 6 :
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.
Question 7 :
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.
Question 8 :
Must my bean-managed persistence mechanism use the WebLogic JTS driver?
Use the TxDataSource for bean-managed persistence.
Question 9 :
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.
Question 10 :
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.