Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
24.2. Entity Beans in EJB 2.x
Important
Clustering 2.x entity beans is is not advised.
Doing so exposes elements that generally are too fine grained for use as remote objects to clustered remote objects and introduces data synchronization problems that are non-trivial.
Do not use EJB 2.x entity bean clustering unless you are in the unique situation of using read-only, or one read-write node with read-only nodes synchronized with the cache invalidation services.
To use a clustered entity bean, the application does not need to do anything special, except for looking up EJB 2.x remote bean references from the clustered HA-JNDI.
To cluster EJB 2.x entity beans, you need to add the
<clustered>
element to the application's jboss.xml
descriptor file. Below is a typical jboss.xml
file.
The EJB 2.x entity beans are clustered for load balanced remote invocations. All the bean instances are synchronized to have the same contents on all nodes.
However, clustered EJB 2.x Entity Beans do not have a distributed locking mechanism or a distributed cache. They can only be synchronized by using row-level locking at the database level (see
<row-lock>
in the CMP specification) or by setting the Transaction Isolation Level of your JDBC driver to be TRANSACTION_SERIALIZABLE
. Because there is no supported distributed locking mechanism or distributed cache Entity Beans use Commit Option "B" by default (see standardjboss.xml
and the container configurations Clustered CMP 2.x EntityBean, Clustered CMP EntityBean, or Clustered BMP EntityBean). It is not recommended that you use Commit Option "A" unless your Entity Bean is read-only.
Note
If you are using Bean Managed Persistence (BMP), you are going to have to implement synchronization on your own.