T
the Rat
Hello all,
I've got an application that does not use entity beans - we are
currently thinking about "porting it" to use CMP 2.0 Entity beans -
mostly for database "independence" reasons - but also because we want
our application to scale. I've been studying CMP 2.0 for awhile and
have some concerns.
The model of our current application is, essentially, a server
application that is contacted by numerous clients all wanting to get
the same resources in a db. Under the current implementation, each
client gets a lock on the resource it wants and then updates the
resource (table row) to show that the resource is "taken" and then
releases the lock. This lock prevents other clients from the mistaken
impression that they also have access to the same resource as the first
client. This system works pretty well.
However, I recently came across something while reading CMP 2.0 Entity
beans that makes me very nervous. It's an excerpt from a jboss 4.0
manual about how clustering CMP 2.0 entity beans is a really bad idea
for a couple of reasons. The excerpt is below - and in fact I may be
misinterpreting it - but it sounds like because I want to have numerous
clients hitting numerous (clustered) application servers - and reading
and writing the same resources in a DB, that I should NOT use CMP 2.0.
To me, this brings into doubt the usefulness of CMP 2.0 beans. Am I
really off base on this?
Your thoughts?
-john
16.4.1. Entity Bean in EJB 2.x
First of all, it is worth to note that clustering 2.x entity beans is a
bad thing to do. Its 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 fit into the sepecial case situation
of read-only, or one read-write node with read-only nodes synched with
the cache invalidation services.
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.
Clustering
JBoss Release 4 477
<jboss>
<enterprise-beans>
<entity>
<ejb-name>nextgen.EnterpriseEntity</ejb-name>
<jndi-name>nextgen.EnterpriseEntity</jndi-name>
<clustered>True</clustered>
<cluster-config>
<partition-name>DefaultPartition</partition-name>
<home-load-balance-policy>
org.jboss.ha.framework.interfaces.RoundRobin
</home-load-balance-policy>
<bean-load-balance-policy>
org.jboss.ha.framework.interfaces.FirstAvailable
</bean-load-balance-policy>
</cluster-config>
</entity>
</enterprise-beans>
</jboss>
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. (There are some design patterns that allow
you to use Commit Option "A" with readmostly
beans. You can also take a look at the Seppuku pattern
http://dima.dhs.org/misc/readOnlyUpdates.html.
JBoss may incorporate this pattern into later versions.)
Note
If you are using Bean Managed Persistence (BMP), you are going to have
to implement synchronization on
your own. The MVCSoft CMP 2.0 persistence engine (see
http://www.jboss.org/jbossgroup/partners.jsp)
provides different kinds of optimistic locking strategies that can work
in a JBoss cluster.
I've got an application that does not use entity beans - we are
currently thinking about "porting it" to use CMP 2.0 Entity beans -
mostly for database "independence" reasons - but also because we want
our application to scale. I've been studying CMP 2.0 for awhile and
have some concerns.
The model of our current application is, essentially, a server
application that is contacted by numerous clients all wanting to get
the same resources in a db. Under the current implementation, each
client gets a lock on the resource it wants and then updates the
resource (table row) to show that the resource is "taken" and then
releases the lock. This lock prevents other clients from the mistaken
impression that they also have access to the same resource as the first
client. This system works pretty well.
However, I recently came across something while reading CMP 2.0 Entity
beans that makes me very nervous. It's an excerpt from a jboss 4.0
manual about how clustering CMP 2.0 entity beans is a really bad idea
for a couple of reasons. The excerpt is below - and in fact I may be
misinterpreting it - but it sounds like because I want to have numerous
clients hitting numerous (clustered) application servers - and reading
and writing the same resources in a DB, that I should NOT use CMP 2.0.
To me, this brings into doubt the usefulness of CMP 2.0 beans. Am I
really off base on this?
Your thoughts?
-john
16.4.1. Entity Bean in EJB 2.x
First of all, it is worth to note that clustering 2.x entity beans is a
bad thing to do. Its 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 fit into the sepecial case situation
of read-only, or one read-write node with read-only nodes synched with
the cache invalidation services.
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.
Clustering
JBoss Release 4 477
<jboss>
<enterprise-beans>
<entity>
<ejb-name>nextgen.EnterpriseEntity</ejb-name>
<jndi-name>nextgen.EnterpriseEntity</jndi-name>
<clustered>True</clustered>
<cluster-config>
<partition-name>DefaultPartition</partition-name>
<home-load-balance-policy>
org.jboss.ha.framework.interfaces.RoundRobin
</home-load-balance-policy>
<bean-load-balance-policy>
org.jboss.ha.framework.interfaces.FirstAvailable
</bean-load-balance-policy>
</cluster-config>
</entity>
</enterprise-beans>
</jboss>
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. (There are some design patterns that allow
you to use Commit Option "A" with readmostly
beans. You can also take a look at the Seppuku pattern
http://dima.dhs.org/misc/readOnlyUpdates.html.
JBoss may incorporate this pattern into later versions.)
Note
If you are using Bean Managed Persistence (BMP), you are going to have
to implement synchronization on
your own. The MVCSoft CMP 2.0 persistence engine (see
http://www.jboss.org/jbossgroup/partners.jsp)
provides different kinds of optimistic locking strategies that can work
in a JBoss cluster.