• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
Bartenders:
  • Piet Souris
  • Jj Roberts
  • fred rosenberger

Entity bean performance

 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Still rookie type question --- Reading the entity bean chapter it seems each bean instance represents a row from one or several tables(joins). I have an application that will display a table format data to front end. Basically each row of the table is obtained from some business logic but essentially from some table joins, so you can say basically each row in the html table maps to one row in database table. Since my output table is huge (more than 2000 rows), does it mean the server will create more than 2000 entity beans for me ? If that's the case, will it cause memory problem or any other performance issue ? How is this issue taken care of by server ?
 
Ranch Hand
Posts: 8944
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Since my output table is huge (more than 2000 rows), does it mean the server will create more than 2000 entity beans for me ? If that's the case, will it cause memory problem or any other performance issue ? How is this issue taken care of by server



Yes it will create 2000 instances which should be avoided. Since you are using the data for display purpose, I would suggest you to use a session bean to read the 2000 rows rather than using entity beans.
 
Pradeep bhatt
Ranch Hand
Posts: 8944
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You may be intrested to read this J2EE design pattern
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ValueListHandler.html
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:


Yes it will create 2000 instances which should be avoided. Since you are using the data for display purpose, I would suggest you to use a session bean to read the 2000 rows rather than using entity beans.



Do you mean if I just "display" without "modifying", I should avoid entity bean ? And use entity bean only when I try to "update" or "modify" data ?
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Sikuluzu:
Do you mean if I just "display" without "modifying", I should avoid entity bean ? And use entity bean only when I try to "update" or "modify" data ?


Entity beans come with a fair amount of baggage in the form of overhead and complexity. Sometimes the payoff is worth the cost, but if you merely need to display some data from a few tables, writing a session bean that uses JDBC to retrieve the data will be far easier and perform better.

Also, Hibernate is a popular and robust replacement for entity beans. While the configuration mapping files can be difficult at first to grok, tools like XDoclet can ease the process considerably. XDoclet also makes EJBs bearable.
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Harkness:

tools like XDoclet can ease the process considerably. XDoclet also makes EJBs bearable.



David , do you have any links to articles/ tutorials to write custom XDoclet templates , subtasks etc (other than the documentation)?

I got the source code and the templates that ship with the tool did help. But an article along the lines of 'advanced XDoclet would be of great help.

Given the number of layers in our application and repetitive code that does delegation , i see lots of places where XDoclet could help.
 
Pradeep bhatt
Ranch Hand
Posts: 8944
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by karthik Guru:


David , do you have any links to articles/ tutorials to write custom XDoclet templates , subtasks etc (other than the documentation)?

I got the source code and the templates that ship with the tool did help. But an article along the lines of 'advanced XDoclet would be of great help.

Given the number of layers in our application and repetitive code that does delegation , i see lots of places where XDoclet could help.



This book talks about extending Xdoclet.
http://www.theserverside.com/articles/article.tss?l=XDocletInActionReview
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, the book review that Pradeep links to (XDoclet in Action) has a 35-page chapter that discusses creating custom templates, tags and tasks. I just skimmed it and it seems to be a good start to get you going.

The user mailing list is quite helpful, and there are enough people that most facets are well-covered (EJB, Hibernate, WebLogic, JBoss, Struts).
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic