Hi all,

I would like to have more information about beans instantiation at the server side and if it implies something in the EJB design of an application.
I�m asking this because I�m having performance problems (apparently at the bean instantiation side) with  a simple EJB design/application.

Suppose a User Entity Bean (CMP) and an Account entity bean (also CMP), the relation between these beans is 1-N. Each bean contains getters and setters and other business method.
In the AccountHome wrapper I�ve defined a findByUser(UserPK) method to receive back all the accounts assigned to a specific user.
 
At the client side, at some point I want to display user�s assigned accounts information. This part of the client application displays only read-only information to the end-user.
To do this I�m using the AccountHome �s  findByUser method to get the Accounts� wrapper objects and for each wrapper, I�m using the GETXXX methods to get the accounts� information I want to display (such as account number, value, etc).
By calling the find method, the EJB server is instantiating an Account Entity Bean for each related account found in the DB and it returns wrappers to them in an enumeration.

This sounds quite simple in theory but after implementing it and testing it with some data in the database (ORACLE 8 RDBMS), I was faced with strange performance issues.

To get the list of accounts for a user, it took more than 5 seconds for only 6 accounts.
Doing some benchmarking by simulating 10 concurrent users (average of 10 assigned accounts per user), it took more than 15 minutes!!!
Note:

I�m using a quite powerful machine (2 pentium III 450 MHZ, 384 MB RAM)
The database is tuned correctly
There are enough ready instances in Beans� pools on the server


I�ve tested manually the DB by executing the same SQL statements as those generated at deployment time and the results are much much faster!!!! (Less than a minute for the same simulation).

So I�ve rewritten the code to use a Session bean that:

Performs the SQL statement directly using JDBC
Put the ResultSet in a serializable vector which is send to the client.


So here, for ReadOnly purposes, I�m not using the AccountHome find method anymore, which mean that no more Account Beans are instantiated and used at the server side.
Account�s beans are instantiated only when �real work� has to be done on the data.

A result of this is that the performance at the client side is excellent�. No latency anymore. The same 10 concurrent users simulation was completed in less than 30 seconds with much more assigned accounts per user.

It seems then that the problem is located at the instantiation of the beans on the server.

In conclusion,  now I�ve the performance I wanted but:

I�ve to put database access code into a session bean to only display data. This means that I don�t have Database independency anymore with this simple design.

Even more, the EJB server (WebLogic 4.0.1) I�m using is providing me a DB Connection pool and I�m using it. But this implies the use of a specific WebLogic parameter to get a connection from the pool. No EJB Server independency anymore�


Any comments on this?
Daniel
 

begin:vcard
n:De Luca;Daniel
tel;fax:+ 32 2 714 42 22
tel;work:+32 2 714 42 64 (direct), +32 2 714 42 11
x-mozilla-html:TRUE
url:http://www.ficsgrp.com
org:<center><a href="http://www.ficsgrp.com"><img SRC="http://www.ficsgrp.com/images/ficstop.gif" ALT="Visit FICS" NOSAVE BORDER=0 height=49 width=150></a></center>;<center>Research & Development</center>
adr:;;Excelsiorlaan, 87;Zaventem;Brussels;B-1930;Belgium
version:2.1
email;internet:[EMAIL PROTECTED]
title:</a><center>Technology Consultant</center>
note:<center><a href="http://www.bejug.org"><IMG SRC="http://www.bejug.org/images/gobejug.gif" ALT="Member of the Belgian Java User Group" HEIGHT=31 WIDTH=88></a><A HREF="http://www.politik-digital.de/spam/"><IMG SRC="http://www.politik-digital.de/spam/en/download/spam_h90.gif" ALT="Vote against SPAM!"  BORDER="0" WIDTH="92" HEIGHT="39"></A></center>
fn:</a><center>Daniel De Luca</center>
end:vcard

Reply via email to