|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
? we are integrated in VM with jetty and tomcat
marcf
|
|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
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
