It could be an misconfiguration problem, but it is also an architectural
one.
You should never access an entity bean from a client (the JSP in this case).
If you look at what is happening you will see why:
1) You do a network call for home look up
2) You do a network call for the findAll(), the server returns the
enumeration
3) You do a network call to get an attribute from the entity bean
3a) The server starts a transaction
3b) server gets attributes from ejb
3c) The server commits the transaction (which can result in a DB update
unless you are using dirty flags)
3d) Server returns value to client (more network traffic)
4) You repeat step 3 for each attributes you fetch
5) You repeat step 4 for each row
Also if this is the first time you have accessed these entity beans, the
server will have to create and data fill them from the database.
As you can see above, you are doing a large number of network calls which
are expensive & a large number of transactions which is even more expensive.
A better approach is to use stateless session beans as Facades for your
entity beans. The session bean talks to your entity beans, data fills a
serializable class (a ValueObject) with the data for each row and returns an
array or collection of these back to the client.
If you do that the client/server flow looks like:
1) You do a network call for home look up for your session bean
2) You do a network call to the home calling create() to get the remote
interface
3) You do a network call to your session bean calling a getRows() method
3a) Server starts a transaction
3b) Session bean lookups the home of the your entity bean (usually a
optimised call since we are in the container already)
3c) Session bean calls findAll() on the entity bean's home and gets an
enumeration of entity beans
3d) Session bean creates a collection
3e) Session bean creates a ValueObject and copies the attributes from the
entity bean to the ValeuObject. (Once again these calls are optimised
because we are in container already)
3f) Session bean adds ValueObject to the collection
3g) Steps 3e, 3f are repeated for each row (entity bean)
3h) Session bean returns collection
3i) Server commits transaction (this could result in DB updates if you don't
have dirty flags on your entity beans)
4) Client processes collection of ValueObjects and generates HTML table
As you can see this method reduces the number of network calls dramatically
and is more scaleable (because Stateless Session Beans are pooled).
Check out some of the patterns at http://www.theserverside.com
Hope that helps
Jonathan
-----Original Message-----
From: Saul Farber [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 5 July 2001 1:01 p.m.
To: [EMAIL PROTECTED]
Subject: [JBoss-user] JBoss performance problems
Hello gurus,
I'm having some performance problems with JBoss right now. Could
someone help me out a bit?
Here's the scenario:
Sun UltraSparc1-170Mhz:
running: +Jboss2.2.1_Jetty3.1.RC4 bundle
+PostgreSQL (ver 7.x)
My app is pretty simple, just direct calls to entity EJB's from JSP's.
However, when I try to load a page that essentially displays a whole
table (all 30 rows) by using Home.findAll(), then running through the
java.util.Enumeration object, it takes close to 30 seconds to load the
page. This seems rather excessive. Could I have something
misconfigured?
If you need more info, please email me. I saw a similar post in the
archives, but couldn't find a response to it.
Thanks,
Saul
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
