WebLogic Server Frequently Asked Questions

FAQs: EJB

General

Stateless Session Beans

Stateful Session Beans

General Entity Bean Questions

Can an entity bean be a listener for JMS messages?

CMP Entity Beans

When are CMP fields loaded? Is it always determined by the finders-load-bean setting? What is the default behavior?
What's the purpose of the delay-database-insert-until deployment descriptor element?
Can I map an entity bean to more than one table?
Can I use a join or intermediate table to implement a One-Many relationship?
Why can't I hold on to a cmr-field (Container Managed Relationship) collection and use it after the transaction commits?
Can a foreign key column in the database be mapped to both a cmp-field and a cmr-field?
Why can't I call the setXXX method for a cmr-field during ejbCreate?
How can I avoid violating NOT NULL constraints on foreign keys that are mapped to cmr-fields?
Does WebLogic support auto generating primary keys for entity beans?

Message Driven Beans

Which security principal does an MDB use to connect to JMS?

EJBs and Transactions

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

A. The EJB Specification prohibits this behavior, and the weblogic.appc 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.

Q. Must EJBs be homogeneously deployed across a cluster? Why?

A. Yes. In WebLogic Server 6.0 and later, EJBs must be homogeneously deployed across a cluster for the following reasons:

To keep clustering EJBs simple
To improve performance by avoiding cross-server calls. If EJBs are not deployed on all servers, cross-server calls are more likely.
To ensure that every EJB is available locall.y
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.

Q. What is the free pool?

A. The free pool is a data structure the EJB container uses to cache anonymous instances of a given bean type. The free pool improves performance by reusing objects and skipping container callbacks when it can.

Q. Where can I get a copy of the EJB specification?

A. You can download it from Sun's EJB site.

Q. Which versions of the EJB specification are supported by WebLogic Server?

A. The following table summarizeds EJB specification support by WebLogic Server version:

WebLogic Server Version	EJB Version
4.5.x	1.0
5.1	1.1
6.0	1.1 and 2.0 (PFDI)
6.01	1.1 and 2.0
7.0	1.1 and 2.0
8.1	1.1 and 2.0

Q. How should I set max-beans-in-free-pool for stateless beans?

A. This is explained in Pooling for Stateless Session EJBs in Programming WebLogic Enterprise JavaBeans.

Q. How should I set initial-beans-in-free-pool for stateless beans?

A. This is explained in Pooling for Stateless Session EJBs in Programming WebLogic Enterprise JavaBeans.

Q. When are stateless EJBs passivated?

A. Stateless ejbs are never passivated. Since stateless ejbs do not have state, there is no need to passivate them. They are put back into the free pool after each method call so they will be available to service other requests.

Q. Can I call remove() on a stateless session bean?

A. Yes. Currently, calling remove() on a stateless session bean is a noop.

Q. When are ejbCreate and ejbRemove called on stateless EJBs?

A. When the stateless beans are created and removed by the EJB container. Note that this does not correspond to calls to create and remove on the stateless home. Depending on your initial-beans-in-free-pool setting, beans may be created by the container during deployment at which point they are placed in the free pool. Aside from during deployment, beans will only be created to service requests when all of the beans in the free pool are in use and the max-beans-in-free-pool limit has not been met. Stateless beans are removed by the EJB container during undeployment.

Q. Can you explain passivation / activation?

A. Passivation and activation are a standard part of a stateful session bean's lifecycle. For details, see Stateful Session EJB Life Cycle in Programming WebLogic Enterprise JavaBeans.

Q. Why did I get a LockTimedOutException?

A. When you get a LockTimedOutException while invoking a stateful session EJB, one of two things has occurred:

You have <allow-concurrent-calls> set to true in your weblogic-ejb-jar.xml descriptor and your call timed out while waiting to be processed. The timeout used in this case is the value <trans-timeout-seconds> element of the weblogic-ejb-jar.xml descriptor or its default value of 30 seconds.
You do not have <allow-concurrent-calls> set to true and you attempt to invoke a stateful session bean that is already busy processing another request. In this case, the second method call will not block and a LockTimedOutException will be thrown immediately.

Q. What is the difference between the NRU and LRU cache?

A. NRU cache works by avoiding passivation as much as possible. Stateful session instances are only passivated when there is memory pressure (your # of beans in the cache approaches the max-beans-in-cache size). This is the 'NRU' option in the weblogic-ejb-jar.xml and the default behavior. The LRU cache works by passivating a bean after it reached its idle-timeout-seconds. So if your max-beans-in-cache was 1000 and you only had 10 beans in memory, it would still write the 10 beans to disk after their timeout period expired. This is the 'LRU' option in weblogic-ejb-jar.xml. This was added to 5.1 and 6.x because there were some customers that wrote applications depending on the timeout behavior. The was also the default behavior in 3.1-4.5.

Q. When should I use a Stateful session bean and when should I use a servlet session?

A. The answer to this question is very application-specific and there are situations in which either approach will work. A stateful session bean provides declaritive transaction and security checking as well as failover to a secondary in a cluster.

Q. How big should I make the cache for a stateful session bean?

A. The cache for a stateful session bean should usually be equal to the maximum number of concurrent clients of the bean. This is generally a much larger value than the number of execute threads in the server, therefore, stateful session beans will use more server resources.

Q. Can an entity bean be a listener for JMS messages?

A. No. Message driven beans should be used to consume JMS messages.

Q. When are CMP fields loaded? Is it always determined by the finders-load-bean setting? What is the default behavior?

A. Finders-load-bean is true by default. A bean is retrieved via a finder explicitly if you call a findXXX() method to get the bean and implicitly if you retrieve the bean via a cmr-field getXXX method. Either of these will result in eager loading of the bean's fields if finders-load-bean is true for the bean.

If you aren't calling a finder, but just accessing the bean via a reference you obtained in a different transaction, then fields are always loaded lazily when using 2.0 CMP, i.e. they aren't read from the DBMS during ejbLoad, but rather when a getXXX() method is called. By default there is a single field group that contains all the fields if you don't define any field groups. So, calling a cmp-field getXXX() method loads all of the persistent state of the bean by default.

Q. What's the purpose of the delay-database-insert-until deployment descriptor element?

A. This setting allows you to specify at what point the database insert occurs when creating a CMP bean. Non-null foreign key constaints in your database can make creating CMP beans with relationships tricky. We offer this setting to give developers more flexibility to satisfy those constraints. Also, this setting is necessary to enable the bulk insert feature that was added in WLS 7.0. To enable the bulk insert feature and to provide yourself the maximum amount of flexibilty to satisfy any non-null foreign key constraints, we recommend setting the delay-database-insert-until option to commit. For more information, see Delaying Database Inserts in Programming WebLogic Enterprise JavaBeans.

Q. Can I map an entity bean to more than one table?

A. In WLS 8.1 it is possible to map an entity bean to multiple tables, however, there are some restrictions. Namely, each table must contain the same primary key columns. The columns can have different names in different tables, but they must contain the same values. When a new bean is created a row will be inserted in each table, and when a bean is removed a row is removed from each table. The rows in each table are related via their primary key values. The rows mapped to a particular entity bean will always have the same primary key value. See Multiple Table Mapping in Programming WebLogic Enterprise JavaBeans.

Q. Can I use a join or intermediate table to implement a One-Many relationship?

A. This is currently not supported. One-Many relationships require that the bean on the Many side of the relationship contain a foreign-key in one of its tables.

Q. Why can't I hold on to a cmr-field (Container Managed Relationship) collection and use it after the transaction commits?

A. This is prohibited by the EJB 2.0 specification. The reason for disallowing this is that the DBMS data backing a cmr-field collection can change in unpredictable ways once your transaction commits. Tracking these changes is difficult and can result in the contents of the cmr-field collection changing when the application doesn't expect it. The bottom line is that developers must retrieve and access cmr-field collections within a single transaction.

Q. Can a foreign key column in the database be mapped to both a cmp-field and a cmr-field?

A. Yes, this has been supported since WLS 6.0 SP1. Note that when the cmp-field is a primary-key field the cmr-field is read-only. In other words, the setXXX method for the cmr-field cannot be used. The value of the primary-key should be initialized as usual in this case. Conversely, when the cmp-field is not a primary-key field, then the cmp-field is read-only. The underlying column is updated via the cmr-field, and the cmp-field just provides a read-only view of the foreign-key.

Q. Why can't I call the setXXX method for a cmr-field during ejbCreate?

A. This is disallowed by the EJB 2.0 specification because the primary-key of the current bean isn't necessarily known during ejbCreate and it may be needed depending on how the relationship is mapped to the underlying DBMS. Cmr-field setters should be called during ejbPostCreate instead of ejbCreate if relationships need to be setup during creation of a bean.

Q. How can I avoid violating NOT NULL constraints on foreign keys that are mapped to cmr-fields?

A. In WLS 7.0 and later, you can set delay-database-insert-until to 'commit' and assign the cmr-field a value before the current transaction commits. You can also set delay-database-insert-until to 'ejbPostCreate' and assign the cmr-field a value during ejbPostCreate.

Q. Does WebLogic support auto generating primary keys for entity beans?

Yes, this feature was added in WLS 6.1. For more information, see the DTD comments for the <automatic-key-generation> element.http://www.bea.com/servers/wls810/dtd/weblogic-ejb-jar.dtd

Q. Which security principal does an MDB use to connect to JMS?

A. As of WLS 6.1 SP2, an MDB uses the same principle to connect to JMS as it does to process messages. This is either the principle that is mapped to the run-as role specified for the bean, or 'guest' if no run-as role is provided. Prior to WLS 6.1 SP2, this behavior was not well defined.

Q. How should I obtain my JDBC connection so that it participates in the EJB container's transaction?

A. You must get your JDBC connection from a TxDataSource or from the JTS driver. If you get a JDBC connections from a plain DataSource or directly from the JDBC driver, it will NOT participate in the EJB container transaction.

TxDataSources are recommended instead of accessing the JTS driver directly. TxDataSources are the standard mechanism in JDBC 2.0 for connection pooling, and they support 2PC/XA transactions.

Q. My transaction aborted, but my database changes did not rollback.

A. See previous question. You must obtain your JDBC connections from a TxDataSource.

Q. Why did my JDBC code throw a rollback SQLException?

A. 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.