File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JBoss/WildFly and the fly likes Is jboss seam framework really slow? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "Is jboss seam framework really slow?" Watch "Is jboss seam framework really slow?" New topic
Author

Is jboss seam framework really slow?

dennis laping
Greenhorn

Joined: Nov 06, 2008
Posts: 7
Hello everyone!

I'm a newbie programmer and currently developing a web application using jboss seam 2.0.1. To those of you who have experienced developing web app using this framework, is your end product web app has a slow response time for some complicated transactions?
I also observed that depending on the number of components in my user interface is also the number of times it initialized the class variables in the backing bean

example:
<s:decorate template="../../../../resources/template/tableLayout.xhtml">
<ui:define name="column1">
<s:decorate template="../../../../resources/template/rowLayrout.xhtml">
<ui:define name="rqd">*</ui:define>
<ui:define name="label1">
<span class="label" style="width:100px">Department Name</span>
</ui:define>
<ui:define name="input1">
<h:inputText id="txtDeptName"
value="#{departmentHome.department.departmentName}"
maxlength="30" />
</ui:define>
</s:decorate>
</ui:define>

<ui:define name="column2">
<s:decorate template="../../../../resources/template/rowLayrout.xhtml">
<ui:define name="rqd">*</ui:define>
<ui:define name="label1">
<span class="label" style="width:100px">Department Code</span>
</ui:define>
<ui:define name="input1">
<h:inputText id="txtDeptCode"
value="#{departmentHome.department.departmentCode}"
maxlength="20"/>
</ui:define>
</s:decorate>
</ui:define>
</s:decorate>

The xhtml code above initialized the class variables in the departmentHome backing bean two times. I believed it's because of the value attribute in the component when it refers to the class variable is invoked.

And one more thing... We also used rich faces on some of the components we used. Can any of you give me a sample implementation on how to properly instantiate a variable in the backing bean for the rich:comboBox? Because on how we implemented it just adds the slowness of the application... Every time the variable for the comboBox is initialized, it queries in the database the data needed to be loaded to the combobox.

Thanks and best regards,
Dennis
Ashok C. Mohan
Ranch Hand

Joined: Dec 03, 2003
Posts: 75
Seam is not slow, but definitely the way you write code may make seam slower than it should be. Fetching data from backing bean with getter methods is a bad idea as these methods will be invoked many many times during a typical JSF lifecycle. Added to this, seam wires all its components with method interceptors which kick in for every method call to the backing bean. This is what makes your application slow. If you add database access code or other heavy-duty code in any of these methods, matters will become worse and you will end up with an application that crawls at a snails pace! But of course there is a way around. If you use factory methods (methods annotated with @Factory) to prepare your lists and objects which are accessed many times, this will reduce the number of invocations to one. As Jacob rightfully points out here, you should also try annotating the methods which do not require the normal seam method interruption with the @ByPassMethodInterceptors annotation. See a post by Dan Allen here which explains this in detail.


SCJP 1.4
Do not dwell in the past, do not dream of the future, concentrate the mind on the present moment.
Mourouganandame Arunachalam
Ranch Hand

Joined: Oct 29, 2008
Posts: 396
Hmmm... that's a great source of information Ashok...


Mourougan
Open Source leads to Open Mind
dennis laping
Greenhorn

Joined: Nov 06, 2008
Posts: 7
Hi Ashok!

Thank you so much for replying and I appreciate the reference links.
What I did now was I added @BypassInterceptor annotation on all of the getters in the backing bean (I'm not sure if that is the right thing, though). It made quite an improvement, about 20% faster now but it's still not enough. I must've missed something...

Also, about my last question. One of the things that could be slowing down the application is the initialization of the variables needed in the rich comboBoxes. An average of 8 comboBoxes are in one of the pages and each of it queries from the database for the records needed to be loaded in it (some can reach up to 1000 records). They are already in the init method for them to be invoked only once, right?... please see below...

@Init
public void init(){

detailsList = new HomeDetailsList<SalesOrderDetails>();
cqComboBox = new RichComboBoxHelper<CustomerQuotations>(new CustomerQuotationQueryBean().getByStatus("quoted"));
cqItemArrayList = new ArrayList<CustomerQuotationDetails>();

cqDetailHash = new HashMap<Long, CustomerQuotationDetails>();
cqDetailSelectedHash = new HashMap<Long, CustomerQuotationDetails>();

//initializes rich combo boxes
customerComboBox = new RichComboBoxHelper<Customers>(new CustomerQueryBean().getListAll());
statusComboBox = new RichComboBoxHelper<Constants>(new ConstantQueryBean().getByModuleCodeConstantType("SO", "Status"));
unitComboBox = new RichComboBoxHelper<Units>(new UnitQueryBean().getListAll());
packagingComboBox = new RichComboBoxHelper<Packagings>( new PackagingQueryBean().getListAll());
contactPersonComboBox = new RichComboBoxHelper<CustomerDetails>();
rfqItemCombobox = new RichComboBoxHelper<RFQItems>(new RFQItemQueryBean().getListAll());
currencyCombobox = new RichComboBoxHelper<Currency>(new ConstantQueryBean().currencyList());
shippingTermsComboBox = new RichComboBoxHelper<ShippingTerms>(new ConstantQueryBean().shippingTermList());
populateShippingModeComboBox();
populatePaymentTerms();

salesOrderDetail = new SalesOrderDetails();
salesOrderDetail.setItem(new Items());
salesOrderDetail.setCrd(new Date());

salesOrder.setSalesOrderNo(formatOrderNo());
salesOrder.setCustomerPODate(new Date());
salesOrder.setDateCreated(new Date());
statusComboBox.setValue("open");

//set flags
forDetailsEditing = false;
forEditing = false;
forViewing = false;
}

I'm interested to know what comboBox component you used. Maybe I can get an idea on how you implented it.

By the way, I'm still about to read Dan Allen's post and I'm also interested in that chapter in their book about multi-layer caching.

Thanks again!
Jacob Orshalick
Author
Ranch Hand

Joined: Mar 30, 2009
Posts: 32
If the list of elements in the combo-box changes rarely (e.g. mostly reference data), you could try caching the queries using the second-level cache of your ORM provider. After the initial load this will speed up subsequent loads of the data dramatically as the data will simply be pulled from cache in-memory. ORM second-level caching is discussed in the multi-layer caching chapter as well


Seam Framework: Experience the Evolution of Java EE | [url]http://solutionsfit.com[/url]
dennis laping
Greenhorn

Joined: Nov 06, 2008
Posts: 7
Thanks Jacob, I will try that.

I've been doing some research and I found out (please correct me if I'm wrong) that I think I have made the invocation of the class variables in the backing bean only once already by instantiating them in the init block with the @Init annotation. There's just no way from keeping Seam in calling the variables more than once, right? I think I just need to research more on caching.

Thanks all,
Dennis
Jacob Orshalick
Author
Ranch Hand

Joined: Mar 30, 2009
Posts: 32
There's just no way from keeping Seam in calling the variables more than once, right?


It is actually JSF that does this when rendering the response, not Seam. If you are accessing the variables as #{myBackingBean.customerComboBox} then yes, it is likely the get method will be invoked more than once during page rendering. The @BypassInterceptors annotation allows you to avoid the overhead of interception by Seam when the get method is invoked by JSF.

I think I have made the invocation of the class variables in the backing bean only once already by instantiating them in the init block with the @Init annotation.


Yes, the init block will initialize the class variables only once, but that init method will be invoked every time the component is created. This means that if your component is scoped to EVENT, it would be invoked every time the page is loaded. If it is scoped to the conversation, every time the conversation is started and so on... In other words, depending on the scenario, the DB access in the init block could still be the performance bottleneck. Caching could certainly help if that is the case.
dennis laping
Greenhorn

Joined: Nov 06, 2008
Posts: 7
Thanks again for your detailed reply, Jacob. I really appreciate it.
I'm sorry about this but I'm kinda confused now about the @Factory method implementation and the @BypassInterceptors. Basically, you have a faster application when you use either or both of them, right? But when do I implement one of it instead of the other on a particular method? How do they differ from each other in terms of usage? By the way, I'm reading your post right now. That's a nice post !

Thanks in advance!
Jacob Orshalick
Author
Ranch Hand

Joined: Mar 30, 2009
Posts: 32
The @Factory basically allows you to initialize a context variable on request. Take a look at the Seam reference docs to learn more about this.

@BypassInterceptors allows you to avoid interception when a method on a Seam component is invoked. This is really a performance tuning technique for those values that need to be retrieved from a Seam component, but are only available by calling on that Seam component.

When to access a value through a component vs. initializing it as a context variable is really situational. I tend to initialize context variables for values that I access frequently.
Jacob Orshalick
Author
Ranch Hand

Joined: Mar 30, 2009
Posts: 32
And I'm glad you liked the post, hope it helps out
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is jboss seam framework really slow?