Question about local vs. remote EJBs *and* clustering

[the Rat]

All,

I have recently began experimenting with CMP 2.0 Entity Beans and have
run into a question. I have a server application that provides
resources to numerous client applications. Because this server
application needs to scale, we are looking at clustering application
servers on multiple machines. From everything that I've read so far,
it sounds as if local entity beans are the way to go for performance
reasons - but that they will not function properly in a clustered
environment. Is this true? If my server app on machine #1 reads the
AccountBean #17 from the database and my server app on machine #2 reads
the AccountBean #17 and they are both local entity beans (representing
the same row in the same table of the db) then I will have two separate
local CMP entity beans (one per machine), correct? If this is the
case, how will the beans "know" about each other?

Imagine the following scenario:

1. husband goes to ATM to check account balance - sees he has $500 in
account.
2. wife goes to different ATM to check the SAME account balance - sees
there is $500 in account.
3. the husband, seeing that there was $500 in the account withdrawals
the $500.
4. the wife, seeing that there had been $500 in the account, attempts
to withdrawal $500 from the same account and is given a hefty
insufficient funds penalty.

The above is a basic problem caused by a "dirty" read. If I am using
local entity beans for the accounts, how is this problem prevented?
The only solution I can see is for the entity beans to actually place
locks on the rows/tables - so that the wife can't see how much money is
in the account until her husband is through updating it.

I've been unable to find a clear answer on this anywhere - the
information that is available on how clustering impacts entity beans is
confusing - at the least the info that I've seen.

Any light you can shed would be appreciated.

-john

 

[Luis]

John,

A clustered J2EE server should behave transparently to any well-behaved
J2EE application.

That is, if your application code *strictly* follows the J2EE
programming conventions and does not rely on external tricks such as
accessing the file system or other local resources, then ensuring
consistency across the cluster is a problem of the J2EE server
implementation, and how you configure the server and deploy the
application on it.

Regards,

Luis.

 

[Jon Martin Solaas]

All,

I have recently began experimenting with CMP 2.0 Entity Beans and have
run into a question. I have a server application that provides
resources to numerous client applications. Because this server
application needs to scale, we are looking at clustering application
servers on multiple machines. From everything that I've read so far,
it sounds as if local entity beans are the way to go for performance
reasons - but that they will not function properly in a clustered
environment. Is this true? If my server app on machine #1 reads the
AccountBean #17 from the database and my server app on machine #2 reads
the AccountBean #17 and they are both local entity beans (representing
the same row in the same table of the db) then I will have two separate
local CMP entity beans (one per machine), correct? If this is the
case, how will the beans "know" about each other?

Imagine the following scenario:

1. husband goes to ATM to check account balance - sees he has $500 in
account.
2. wife goes to different ATM to check the SAME account balance - sees
there is $500 in account.
3. the husband, seeing that there was $500 in the account withdrawals
the $500.
4. the wife, seeing that there had been $500 in the account, attempts
to withdrawal $500 from the same account and is given a hefty
insufficient funds penalty.

The above is a basic problem caused by a "dirty" read. If I am using
local entity beans for the accounts, how is this problem prevented?
The only solution I can see is for the entity beans to actually place
locks on the rows/tables - so that the wife can't see how much money is
in the account until her husband is through updating it.

I've been unable to find a clear answer on this anywhere - the
information that is available on how clustering impacts entity beans is
confusing - at the least the info that I've seen.

Any light you can shed would be appreciated.

-john

If you are going to use container managed relationships you have to use
the Local interface of your Entity Beans. Regarding your problem I can't
see how avoiding local interfaces will solve anything you describe at
all. The problem really has to do with accessing the database through
two concurrent database connections, and thus in separate transactions.
The actual side-effects you will experience depends on the transaction
isolation level in the database. The same problem will also occur in
non-distributed environments.

If you have two bean instances on separate machines representing the
same row in the database, and having remote interfaces only, you still
have to consider how to handle the problem you describe.

Using local interfaces in a distributed environment is more of an
arcitectual issue really. I've seen example code at www.javasoft.com
where local entity bean interfaces is called directly from jsp code.
Still it should work in a clustered environment, but then all processing
required to handle the actual http-session, including all the way down
to the database, business logic processing etc. etc., must run in the
same jvm on the same machine. If the load is getting high on the local
node, idle nodes in the cluster cannot take over part of the workload,
because there are no remote calls to redirect for the load balancer.

When you use entity beans the local interfaces really helps on
performance. When running queries, lots of instances will be created,
and lots of get and set methods called. Running this over a remote
interface really has consequences for performance. Especially when using
container managed relationships where instantiation of one bean may
result in a number of other instances being created as well (in essence
a sql join is performed behind the scenes).

Because of this it is recommended to put a business facades (Session
beans) over the entity beans. The facades can have both remote and local
interfaces. The entity-beans themselves should only have local
interfaces, and only the facades should access those interfaces. Also
the methods in the facades should be "coarse grained"; in order to
reduce the number of remote calls in the application, methods where only
very limited pieces of information is transfered at a time, should be
avoided.