JSF ugliness
I am now involved in a real life JSF project. I see clear performance problems with this API. I will share some of my concerns here. Comments and suggestions are welcome.
1. Unnecessary database access. Consider a form where input items are populated with database data. When the form is submitted, system needs to recreate the form in memory. Data is fetched again from the database. This database access is completely unnecessary and unrelated to the business logic that will process the form submission. What a waste.
2. Same problem exists with dataTable, if the table includes commandLink or commandButton. When a link is clicked, the entire table will be recreated in memory. I have seen examples from the so called experts. They cache the managed bean with the table data in the session. Now, we are trading one evil with another. What a waste.
3. There is no default action handler for a form. What happens when a user hits enter while the focus is on a text box? The action handler associated with the commandButton does not get called.
4. I looked into a few third party custom controls. They plain scare me. The Tomahawk controls from MyFaces install a filter. The filter caches the entire response in memory. Then presumably it does something with the buffer before flushing it out to the network. I am sure they do this because they had to and there was no other way.
I am used to coding that optimizes database, memory and network usage down to the last byte. I can trade some degree of inefficiency in exchange for rapid development. But, I have not seen so much wastage in an API in a long time.
[1649 byte] By [
bibhas2a] at [2007-10-2 17:04:42]
> 1. Unnecessary database access. ....................
If you use Hibernate or similar this is not a problem. Although you have reason in this part. In the case when you don't have Hibernate or similar, then you can cache the values yourself, and have better performance.
> 2. Same problem exists with dataTable, if the table.....................
I'm not sure about this, but i think you're right,
> 3. There is no default action handler for a form......................
Use the j4j component....
http://www.jsftutorials.net/param.html
> 4. I looked into a few third party custom controls.................
There are so many outthere...
There are several ways of doing things.
JSF is a growing technology. Give it time to grow. You will see...
By the way
Are you a web programmer?
Are you used to build web applications?
What is the technology that you use?
Thanks for the reply.
> If you use Hibernate
I don't see how it will provide a third alternative to a) Cache all the data in the JVM, b) Re-fetch the data.
> Give it time to grow. You will see
I am OK with that. However, I have an impression that Microsoft is far ahead in the similar space.
> What is the technology that you use?
My preferred approach is Struts. I can write highly optimized code and yet get good development efficiency. For the model layer, I prefer POJO or Session EJB.
Hibernate makes caching for you...Came on....Is Micro$oft code optimized?
> Hibernate makes caching for you...
I think you are missing the point. One should not have to cache large amounts of database data in session just because JSF needs to rebuild the form when submitted. Hibernate will do the caching for you but that does not solve the underlying problem. In a large application, pretty soon, you will have the session full of database data. In a clustered environment, the session may be backed up in the database as blob. Imagine the performance nightmare.
> Is Micro$oft code optimized?
Not sure. Let's keep it out of the discussion.
Let me rephrase the response a little. Hibernate caching is done per JVM and not per user session. That is indeed better than per session caching. This is a good point made by the earlier poster and something to keep in mind.
It may be a moot point for those using Hibernate, but I find that this behaviour of retrieving the data once again every time a page is submitted is very annoying. Why do we have to retrieve the data for the page once again when we know we are navigating to a different page (the page will obviously not be rendred once again)? This retrieval can be a very expensive operation. My biggest issue with it is that there is no way to prevent this unnecessary processing. No JSF property, no custom view handlers, no filters, nothing. Why do we force developers to write an additional caching layer, which isn't always obvious to implement by the way? I would hope that this issue gets addressed at some point.
Martin
I am glad u brought up this topic. I am trying to optimize a large enterprise project that uses JSF heavily and what I am finding is amazing. More than the issues you are talking about, JSF issues are much more fundamental: An analysis of core dump shows over 1 MB of usage per session most of which is consumed by Hash tables, Hash table entries and partial HTML JSF creates while creating the component tree.
For about 100 concurrent users, I see about
100,000 hashtables consuming 8 MB. These hashtables store, in total, of about 1 million hashtable$entry objects for a total of 70 MB. And, there are plenty of string objects too (created for HTML fragments for each component)
Although we use EJB, JDBC, MQ very heavily, the above 3 (strings, hash table and hashtable$entry) objects are the ones which are blowing the house down
regards,
