BEA Home  |  Events  |  Solutions  |  Partners  |  Products  |  Services  |  Download  |  Developer Center  |  WebSUPPORT
	e-docs.bea.com   |   Site Map   |   Search   |   Download Documentation   |   Contact   |   Glossary
|     WebLogic Server Doc Home   |     Programming WebLogic EJB   |   Previous Topic   |   Next Topic   |   Contents   |   View as PDF

weblogic-ejb-jar.xml Document Type Definitions

The following sections describe the EJB 5.1 and EJB 6.0 deployment descriptor elements found in the weblogic-ejb-jar.xml file, the weblogic-specific XML document type definitions (DTD) file. Use these definitions to create the WebLogic-specific weblogic-ejb-jar.xml file that is part of your EJB deployment.

Note: Use the 6.0 deployment descriptors with the 6.x version of WebLogic Server.

• EJB Deployment Descriptors

• DOCTYPE Header Information

• Changed EJB Deployment Elements in WebLogic Server 6.1

• 6.0 weblogic-ejb-jar.xml Deployment Descriptor File Structure

• 6.0 weblogic-ejb-jar.xml Deployment Descriptor Elements

• 5.1 weblogic-ejb-jar.xml Deployment Descriptor File Structure

• 5.1 weblogic-ejb-jar.xml Deployment Descriptor File Structure

EJB Deployment Descriptors

The EJB deployment descriptors contain structural and application assembly information for an enterprise bean. You specify this information by specifying values for the deployment descriptors in three EJB XML DTD files. These files are:

• ejb-jar.xml

• weblogic-ejb-jar.xml

• weblogic-cmp-rdbms-jar.xml

You package these three XML files with the EJB and other classes into a deployable EJB component, usually a JAR file, called ejb.jar.

The ejb-jar.xml file is based on the deployment descriptors found in Sun Microsystems's ejb.jar.xml file. The other two XML files are weblogic-specific files that are based on the deployment descriptors found in weblogic-ejb-jar.xml and weblogic-cmp-rdbms-jar.xml.

DOCTYPE Header Information

When you edit or create XML deployment files, it is critical to include the correct DOCTYPE header for the deployment file. In particular, using an incorrect PUBLIC element within the DOCTYPE header can result in parser errors that may be difficult to diagnose.

The correct text for the PUBLIC elements for the WebLogic Server-specific weblogic-ejb-jar.xml file are as follows.

The correct text for the PUBLIC elements for the Sun Microsystem-specific ejb-jar.xml file are as follows.

For example, the entire DOCTYPE header for a weblogic-ejb-jar.xml file is as follows:

<!DOCTYPE weblogic-ejb-jar PUBLIC 
'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN' 
'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>

XML files with incorrect header information may yield error messages similar to the following, when used with a utility that parses the XML (such as ejbc):

SAXException: This document may not have the identifier `identifier_name'

identifier_name generally includes the invalid text from the PUBLIC element.

Document Type Definitions (DTDs) for Validation

The contents and arrangement of elements in your XML files must conform to the Document Type Definition (DTD) for each file you use. WebLogic Server ignores the DTDs embedded within the DOCTYPE header of XML deployment files, and instead uses the DTD locations that were installed along with the server. However, the DOCTYPE header information must include a valid URL syntax in order to avoid parser errors.

Note: Most browsers do not display the contents of files having the .dtd extension. To view the DTD file contents in your browser, save the links as text files and view them with a text editor.

weblogic-ejb-jar.xml

The following links provide the new public DTD locations for the weblogic-ejb-jar.xml deployment files used with the WebLogic Server:

• For weblogic-ejb-jar.xml 6.0 DTD:

  http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd contains the DTD used for creating weblogic-ejb-jar.xml, which defines EJB properties used for deployment to WebLogic Server.

• For weblogic-ejb-jar.xml 5.1 DTD:

  weblogic-ejb-jar.dtd contains the DTD used for creating weblogic-ejb-jar.xml, which defines EJB properties used for deployment to WebLogic Server. This file is located at http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd

ejb-jar.xml

The following links provide the public DTD locations for the ejb-jar.xml deployment files used with WebLogic Server:

• For ejb-jar.xml 2.0 DTD:

  http://www.java.sun.com/dtd/ejb-jar_2_0.dtd contains the DTD for the standard ejb-jar.xml deployment file, required for all EJBs. This DTD is maintained as part of the JavaSoft EJB 2.0 specification; refer to the JavaSoft specification for information about the elements used in ejb-jar.dtd.

• For ejb-jar.xml 1.1 DTD:

  ejb-jar.dtd contains the DTD for the standard ejb-jar.xml deployment file, required for all EJBs. This DTD is maintained as part of the JavaSoft EJB 1.1 specification; refer to the JavaSoft specification for information about the elements used in ejb-jar.dtd.

Note: Refer to the appropriate JavaSoft EJB specification for a description of the ejb-jar.xml deployment descriptors.

Changed EJB Deployment Elements in WebLogic Server 6.1

These changes were made to weblogic-ejb-jar.xml in WebLogic Server 6.1:

• cache-type was added.

• ejb-local-reference-description was added.

• invalidation-target was added.

• jms-client-id was added.

• jms-polling-interval-seconds was added.

6.0 weblogic-ejb-jar.xml Deployment Descriptor File Structure

The WebLogic Server 6.0 weblogic-ejb-jar.xml deployment descriptor file describes the elements that are unique to WebLogic Server. Although you can use both versions of the deployment descriptors in the EJB container, the WebLogic Server 6.0 version of weblogic-ejb-jar.xml is different from the version shipped with WebLogic Server Version 5.1.

The WebLogic Serve 6.0 weblogic-ejb-jar.xml includes elements for enabling stateful session EJB replication, configuring entity EJB locking behavior, and assigning JMS Queue and Topic names for message-driven beans.

The top level elements in the WebLogic Server 6.0 weblogic-ejb-jar.xml are as follows:

• description

• weblogic-version

• weblogic-enterprise-bean

  • ejb-name

  • entity-descriptor | stateless-session-descriptor | stateful-session-descriptor | message-driven-descriptor

  • transaction-descriptor

  • reference-descriptor

  • enable-call-by-reference

  • jndi-name

• security-role-assignment

• transaction-isolation

6.0 weblogic-ejb-jar.xml Deployment Descriptor Elements

• allow-concurrent-calls

• cache-type

• connection-factory-jndi-name

• description

• ejb-local-reference-description

• ejb-name

• ejb-reference-description

• ejb-ref-name

• enable-call-by-reference

• entity-cache

• entity-clustering

• entity-descriptor

• concurrency-strategy

• db-is-shared

• delay-updates-until-end-of-tx

• destination-jndi-name

• finders-load-bean

• home-call-router-class-name

• home-is-clusterable

• home-load-algorithm

• idle-timeout-seconds

• initial-beans-in-free-pool

• is-modified-method-name

• isolation-level

• jndi-name

• lifecycle

• max-beans-in-cache

• max-beans-in-free-pool

• message-driven-descriptor

• method

• method-intf

• method-name

• method-param

• method-params

• passivation-strategy

• persistence

• persistence-type

• persistence-use

• persistent-store-dir

• pool

• principal-name

• read-timeout-seconds

• reference-descriptor

• replication-type

• res-ref-name

• resource-description

• role-name

• security-role-assignment

• stateful-session-cache

• stateful-session-clustering

• stateful-session-descriptor

• stateless-bean-call-router-class-name

• stateless-bean-is-clusterable

• stateless-bean-load-algorithm

• stateless-bean-methods-are-idempotent

• stateless-clustering

• stateless-session-descriptor

• transaction-descriptor

• transaction-isolation

• trans-timeout-seconds

• type-identifier

• type-storage

• type-version

• initial-context-factory

• invalidation-target

• jms-client-id

• jms-polling-interval-seconds

• provider-url

• res-env-ref-name

• resource-description

• run-as-identity-principal

• weblogic-ejb-jar

• weblogic-enterprise-bean

allow-concurrent-calls

Function

The allow-concurrent-calls element specifies whether a stateful session bean instance allows concurrent method calls. By default, allows-concurrent-calls is false. However, when this value is set to true, the EJB container blocks the concurrent method call and allows it to proceed when the previous call has completed.

Example

See stateful-session-descriptor.

cache-type

Function

The cache-type element specifies the order in which EJBs are removed from the cache. The values are:

• Least recently used (LRU)

• Not recently used (NRU)

Example

The following example shows the structure of the cache-type element.

<stateful-session-cache> 

<cache-type>NRU</cache-type>

</stateful-session-cache>

connection-factory-jndi-name

Function

The connection-factory-jndi-name element specifies the JNDI name of the JMS Connection Factory that the message-driven bean should look up to create its queues and topics. If this element is not specified, the default is the weblogic.jms.MessageDrivenBeanConnectionFactory in config.xml.

Example

<message-driven-descriptor>
      <connection-factory-jndi-name>weblogic.jms.MessageDrivenBean
        ConnectionFactory</connection-factory-jndi-name>
</message-driven-descriptor>

concurrency-strategy

Function

The concurrency-strategy element specifies how the container should manage concurrent access to an entity bean. Set this element to one of three values:

• Exclusive causes WebLogic Server to place an exclusive lock on cached entity EJB instances when the bean is associated with a transaction. Other requests for the EJB instance block until the transaction completes. This option was the default locking behavior for WebLogic Server versions 3.1 through 5.1.

• Database causes WebLogic Server to defer locking requests for an entity EJB to the underlying datastore. With the Database concurrency strategy, WebLogic Server does not cache the intermediate results of entity EJBs involved in a transaction. This is the current default option.

• ReadOnly designates an entity EJB that is never modified. WebLogic Server calls ejbLoad() for ReadOnly beans based on the read-timeout-seconds parameter.

SeeLocking Services for Entity EJBs for more information on the Exclusive and Database locking behaviors. SeeRead-Only Multicast Invalidation for more information about read-only entity EJBs.

Example

The following entry identifies the AccountBean class as a read-only entity EJB:

<weblogic-enterprise-bean>

	<ejb-name>AccountBean</ejb-name>

	<entity-descriptor>

		<entity-cache>

			
<concurrency-strategy>ReadOnly</concurrency-strategy>

		</entity-cache>

	</entity-descriptor>

</weblogic-enterprise-bean>

db-is-shared

Function

The db-is-shared element applies only to entity beans. When it is set to true, WebLogic Server assumes that EJB data can be modified between transactions and reloads the data at the beginning of each transaction. When set to false, WebLogic Server assumes that it has exclusive access to the EJB data in the persistent store. See Using db-is-shared to Limit Calls to ejbLoad() for more information.

Example

See persistence.

delay-updates-until-end-of-tx

Function

Set the delay-updates-until-end-of-tx element to true (the default) to update the persistent store of all beans in a transaction at the completion of the transaction. This setting generally improves performance by avoiding unnecessary updates. However, it does not preserve the ordering of database updates within a database transaction.

If your datastore uses an isolation level of TRANSACTION_READ_UNCOMMITTED, you may want to allow other database users to view the intermediate results of in-progress transactions. In this case, set delay-updates-until-end-of-tx to false to update the bean's persistent store at the conclusion of each method invoke. See ejbLoad() and ejbStore() Behavior for Entity EJBs for more information.

Note: Setting delay-updates-until-end-of-tx to false does not cause database updates to be "committed" to the database after each method invoke; they are only sent to the database. Updates are committed or rolled back in the database only at the conclusion of the transaction.

Example

The following example shows a delay-updates-until-end-of-tx stanza.

<entity-descriptor>

	<persistence>

		
<delay-updates-until-end-of-tx>false</delay-updates-until-end-of-
tx>

	</persistence>

</entity-descriptor>

description

Function

The description element is used to provide text that describes the parent element.

Example

The following examples specifies the description element.

destination-jndi-name

Function

The destination-jndi-name element specifies the JNDI name used to associate a message-driven bean with an actual JMS Queue or Topic deployed in the in WebLogic Server JNDI tree.

Example

See message-driven-descriptor.

ejb-name

Function

ejb-name specifies the name of an EJB to which WebLogic Server applies isolation level properties. This name is assigned by the ejb-jar file's deployment descriptor. The name must be unique among the names of the enterprise beans in the same ejb.jar file. The enterprise bean code does not depend on the name; therefore the name can be changed during the application-assembly process without breaking the enterprise bean's function. There is no built-in relationship between the ejb-name in the deployment descriptor and the JNDI name that the deployer will assign to the enterprise bean's home.

Example

See method.

ejb-reference-description

Function

The ejb-reference-description element maps the JNDI name in the WebLogic Server of an EJB that is referenced by the bean in the ejb-reference element.

• ejb-ref-name specifies a resource reference name. This is the reference that the EJB provider places within the ejb-jar.xml deployment file.

• jndi-name specifies the JNDI name of an actual resource factory available in WebLogic Server.

Example

The ejb-reference-description stanza is shown here:

<ejb-reference-description>

	<ejb-ref-name>AdminBean</ejb-ref-name>

		<jndi-name>payroll.AdminBean</jndi-name>

	</ejb-reference-description>

ejb-ref-name

Function

The ejb-ref-name element specifies a resource reference name. This element is the reference that the EJB provider places within the ejb-jar.xml deployment file.

Example

The ejb-ref-name stanza is shown here:

<reference-descriptor>

	<ejb-reference-description>

		<ejb-ref-name>AdminBean</ejb-ref-name>

		<jndi-name>payroll.AdminBean</jndi-name>

	</ejb-reference-description>

</reference-descriptor>

ejb-local-reference-description

Function

The ejb-local-reference-description element maps the JNDI name of an EJB in the WebLogic Server that is referenced by the bean in the ejb-local ref element.

Example

The following example shows the ejb-local-reference-description element.

<ejb-local-reference-description>

	<ejb-ref-name>AdminBean</ejb-ref-name>

	<jndi-name>payroll.AdminBean</jndi-name>

</ejb-local-reference-description>

enable-call-by-reference

Function

By default, EJB methods called from within the same EAR pass arguments by reference. This increases the performance of method invocation because parameters are not copied.

If you set enable-call-by-reference to False, parameters to the EJB methods are copied (pass-by-value) in accordance with the EJB 1.1 specification. Pass by value is always necessary when the EJB is called remotely (not from within the same application).

Example

The following example enables pass-by-value for EJB methods:

<weblogic-enterprise-bean>

	<ejb-name>AccountBean</ejb-name>

	...

	<enable-call-by-reference>false</enable-call-by-reference>

</weblogic-enterprise-bean>

entity-cache

Function

The entity-cache element defines the following options used to cache entity EJB instances within WebLogic Server:

• max-beans-in-cache

• idle-timeout-seconds

• read-timeout-seconds

• concurrency-strategy

See EJB Life Cycle for a general discussion of the caching services available in WebLogic Server.

Example

<entity-descriptor>

	<entity-cache>

		<max-beans-in-cache>...</max-beans-in-cache>

		<idle-timeout-seconds>...</idle-timeout-seconds>

		<read-timeout-seconds>...<read-timeout-seconds>

		<concurrency-strategy>...</concurrency-strategy>

	</entity-cache>

	<lifecycle>...</lifecycle>

	<persistence>...</persistence>

	<entity-clustering>...</entity-clustering>

</entity-descriptor>

entity-clustering

Function

The entity-clustering element uses the following options to specify how an entity bean will be replicated in a WebLogic cluster:

• home-is-clusterable

• home-load-algorithm

• home call-router-class-name

Example

The following excerpt shows the structure of a entity-clustering stanza:

<entity-clustering>

	<home-is-clusterable>true</home-is-clusterable>

	<home-load-algorithm>random</home-load-algorithm>

	
<home-call-router-class-name>beanRouter</home-call-router-class-n
ame>

</entity-clustering>

entity-descriptor

Function

The entity-descriptor element specifies the following deployment parameters that are applicable to an entity bean:

• pool

• entity-cache

• lifecycle

• persistence

• entity-clustering

Example

The following example shows the structure of the entity-descriptor stanza:

<entity-descriptor>

	<entity-cache>...</entity-cache>

	<lifecycle>...</lifecycle>

	<persistence>...</persistence>

	<entity-clustering>...</entity-clustering>

</entity-descriptor>

finders-load

Function

The finders-load-bean element determines whether WebLogic Server loads the EJB into the cache after a call to a finder method returns a reference to the bean. If you set this element to true, WebLogic Server immediately loads the bean into the cache if a reference to a bean is returned by the finder. If you set this element to false, WebLogic Server does not load automatically load the bean into the cache until the first method invocation; this behavior is consistent with the EJB 1.1 specification.

Example

The following entry specifies that EJBs are loaded into the WebLogic Server cache automatically when a finder method returns a reference to the bean:

<entity-descriptor>

	<persistence>

		<finders-load-bean>true</finders-load-bean>

	</persistence>

</entity-descriptor>

home-call-router-class-name

Function

home-call-router-class-name specifies the name of a custom class to use for routing bean method calls. This class must implement weblogic.rmi.cluster.CallRouter(). If specified, an instance of this class is called before each method call. The router class has the opportunity to choose a server to route to based on the method parameters. The class returns either a server name or null, which indicates that the current load algorithm should select the server.

Example

See entity-clustering and stateful-session-clustering.

home-is-clusterable

Function

Use home-is-clusterable to specify whether the home interface of an entity, stateless session, or stateful session bean is clustered.

When home-is-clusterable is true for an EJB deployed to a cluster, each server instance binds the bean's home interface to its cluster JNDI tree under the same name. When a client requests the bean's home from the cluster, the server instance that does the look-up returns a EJBHome stub that has a reference to the home on each server.

When the client issues a create() or find() call, the stub routes selects a server from the replica list in accordance with the load balancing algorithm, and routes the call to the home interface on that server. The selected home interface receives the call, and creates a bean instance on that server instance and executes the call, creating an instance of the bean.

Example

See entity-clustering.

home-load-algorithm

Function

home-load-algorithm specifies the algorithm to use for load balancing between replicas of the EJB home. If this property is not defined, WebLogic Server uses the algorithm specified by the server property, weblogic.cluster.defaultLoadAlgorithm.

You can define home-load-algorithm as one of the following values:

• round-robin: Load balancing is performed in a sequential fashion among the servers hosting the bean.

• random: Replicas of the EJB home are deployed randomly among the servers hosting the bean.

• weight-based: Replicas of the EJB home are deployed on host servers according to the servers' current workload.

Example

See entity-clustering and stateful-session-clustering.

idle-timeout-seconds

Function

idle-timeout-seconds defines the maximum length of time a stateful session EJB should remain in cache. After this time has elapsed, WebLogic Server removes the bean instance if the number of beans in cache approaches the limit of max-beans-in-cache. The removed bean instances are passivated. See EJB Life Cycle for more information.

Note: Although idle-timeout-seconds appears in the entity-cache stanza, WebLogic Server 6. 1 does not uses its value in managing the lifecycle of entity EJBs— idle-timeout-seconds has no effect on when entity beans are removed from cache.

Example

The following entry indicates that the stateful session EJB, AccountBean, should become eligible for removal if max-beans-in-cache is reached and the bean has been in cache for 20 minutes:

<weblogic-enterprise-bean>

	<ejb-name>AccountBean</ejb-name>

	<stateful-session-descriptor>

		<stateful_session-cache>

			<max-beans-in-cache>200</max-beans-in-cache>

			
<idle-timeout-seconds>1200</idle-timeout-seconds>

		</stateful-session-cache>

	</stateful-session-descriptor>

</weblogic-enterprise-bean>

initial-beans-in-free-pool

Function

If you specify a value for initial-beans-in-free-pool, you set the initial size of the pool. WebLogic Server populates the free pool with the specified number of bean instances for every bean class at startup. Populating the free pool in this way improves initial response time for the EJB, because initial requests for the bean can be satisfied without generating a new instance.

Example

See pool.

initial-context-factory

Function

The initial-context-factory element specifies the initial contextFactory that the container will use to create its connection factories. If initial-context-factory is not specified, the default will be weblogic.jndi.WLInitialContextFactory.

Example

The following example specifies the initial-context-factory element.

<message-driven-descriptor>

<initial-context-factory>weblogic.jndi.WLInitialContextFactory
</initial-context-factory>

</message-driven-descriptor>

invalidation-target

Function

The invalidation-target element specifies a Read-Only entity EJB that should be invalidated when this container-managed persistence entity EJB has been modified.

Example

The following entry specifies that the EJB named StockReaderEJB should be invalidated when the EJB has been modified.

<invalidation-target>

	<ejb-name>StockReaderEJB</ejb-name>

</invalidation-target>

is-modified-method-name

Function

is-modified-method-name specifies a method that WebLogic Server calls when the EJB is stored. The specified method must return a boolean value. If no method is specified, WebLogic Server always assumes that the EJB has been modified and always saves it.

Providing a method and setting it as appropriate can improve performance for EJB 1.1-compliant beans, and for beans that use bean-managed persistence. However, any errors in the method's return value can cause data inconsistency problems. SeeUsing is-modified-method-name to Limit Calls to ejbStore() (EJB 1.1 Only) for more information.

Note: isModified() is no longer required for 2.0 CMP entity EJBs based on the EJB 2.0 specification However, it still applies to BMP and 1.1 CMP EJBs. When you deploy EJB 2.0 entity beans with container-managed persistence, WebLogic Server automatically detects which EJB fields have been modified, and writes only those fields to the underlying datastore.

Example

The following entry specifies that the EJB method named semidivine will notify WebLogic Server when the EJB has been modified:

<entity-descriptor>

	<persistence>

		
<is-modified-method-name>semidivine</is-modified-method-name>

	</persistence>

</entity-descriptor>

isolation-level

Function

isolation-level specifies the isolation level for all of the EJB's database operations. The following are possible values for isolation-level:

• TRANSACTION_READ_UNCOMMITTED: The transaction can view uncommitted updates from other transactions.

• TRANSACTION_READ_COMMITTED: The transaction can view only committed updates from other transactions.

• TRANSACTION_REPEATABLE_READ: Once the transaction reads a subset of data, repeated reads of the same data return the same values, even if other transactions have subsequently modified the data.

• TRANSACTION_SERIALIZABLE: Simultaneously executing this transaction multiple times has the same effect as executing the transaction multiple times in a serial fashion.

Refer to your database documentation for more information on the implications and support for different isolation levels.

Example

See transaction-isolation.

jms-client-id

Function

The jms-client-id element specifies the client ID associated with the message-driven bean. This ID is necessary for durable subscriptions to JMS topics.

The JMS specification allows JMS consumers to specify an associated ID. A message-driven bean with a durable subscription needs an associated client ID. If you use a separate connection factory, you can set the client ID on the connection factory. In this case, the message-driven bean uses this client ID.

If the associated client ID does not have a client ID or if you are using the default connection factory, the message-driven bean uses the jms-client-id value as its client ID.

Example

The following example specifies the use of the jms-client-id element.

<jms-client-id>MyClientID</jms-client-id>

jms-polling-interval-seconds

Function

The jms-polling-interval-seconds element determines the number of seconds between each attempt by WebLogic Server to reconnect to the JMS destination.

Each message-driven bean listens on an associated JMS destination. If the JMS destination is located on another WebLogic Server instance or a foreign JMS provider, the JMS destination may become unreachable. In this case, the EJB container automatically attempts to reconnect to the JMS server. Once the JMS server is running again the message-driven bean can again receive JMS messages.

Refer to your database documentation for more information on the implications and support for different isolation levels.

Example

The following example specifies the use of the jms-polling-interval-seconds element.

<jms-polling-interval-seconds>5</jms-polling-interval-seconds>

jndi-name

Function

jndi-name specifies the JNDI name of an actual EJB, resource, or reference available in WebLogic Server.

Example

See resource-description and ejb-reference-description.

local-jndi-name

Function

The local-jndi-name element specifies a jndi-name for a bean's local home. If a bean has both a remote and a local home, then it must have two JNDI names; one for each home.

Example

The following example shows the specifies the local-jndi-name element.

<local-jndi-name>weblogic.jndi.WLInitialContext
</local-jndi-name>

lifecycle

Function

The lifecycle element defines options that affect the lifecycle of stateful and entity EJB instances within WebLogic Server. Currently, the lifecycle element includes only one element: passivation-strategy.

Example

The following example shows the specifies the lifecycle element.

<entity-descriptor>

	<lifecycle>

		<passivation-strategy>...</passivation-strategy>

	</lifecycle>

</entity-descriptor>

max-beans-in-cache

Function

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. max-beans-in-cache also affects when EJBs are removed from the WebLogic Server cache, as described inLocking Services for Entity EJBs.

Example

The following entry enables WebLogic Server to cache a maximum of 200 instances of the AccountBean class:

<weblogic-enterprise-bean>

	<ejb-name>AccountBean</ejb-name>

	<entity-descriptor>

		<entity-cache>

			<max-beans-in-cache>200</max-beans-in-cache>

		</entity-cache>

	</entity-descriptor>

</weblogic-enterprise-bean>

max-beans-in-free-pool

Function

WebLogic Server maintains a free pool of EJBs for every stateless session, message-driven, and entity bean class max-beans-in-free-pool limits the size of the free pool. For more information, see EJB Life Cycle.

Example

See pool.

message-driven-descriptor

Function

The message-driven-descriptor element associates a message-driven bean with a JMS destination in WebLogic Server. This element specifies the following deployment parameters:

• pool

• destination-jndi-name

• initial-context-factory

• provider-url

• connection-factory-jndi-name

Example

The following example shows the structure of the message-driven-descriptor stanza:

<message-driven-descriptor>

	<destination-jndi-name>...</destination-jndi-name>

</message-driven-descriptor>

method