FAQs: EJB

 

• Why did my JDBC code throw a rollback SQLException?

• Must my bean-managed persistence mechanism use the WebLogic JTS driver?

• Why is there no polymorphic-type response from a create() or find() method?

• Must EJBs be homogeneously deployed across a cluster? Why?

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?

We recommend that you 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.