Hi All,We have developed a very simple Enterprise application in the utilities sector. The application uses Stateless session beans, Value objects and is web-based. The application currently in its testing phase is facing huge problems of screen response times. To this affect would apprciate any ideas by which we can improve the performance. One which comes to our mind is some kind of 'screen-caching' but then the application presents data based on the user who has logged into the system. Basically the application presents user-specific data with some parts of generic data. We tried using JCS but it looks like therez a lot of effort involved and might even need to change the code a lot for such a solution.What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

Hi, Thanks for the response.But we have done all performance measurements and tuned the code as much as possible according to the recommendations. But the things is that we are now out of options and hence looking for the caching solution.

What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

If you are currently doing local caching and using the collections API to do it, Coherence can plug in quickly and easily:

i dont think Coherence will solve your problem. what oyu should look for is ValueListHandler. i.e if you are wanting to cache the results sets

When an application uses enterprise beans in the business tier, it may be preferable to implement a session bean that uses the ValueListHandler. In that case, the session bean simply fronts an instance of a ValueListHandler. Thus, the session bean may be implemented as a stateful session bean to hold on to the list handler as its state, and thus may simply act as a facade

Thanks Rob and Shahrukh,Shahrukh your suggestion is valid but the only problem is that as i mentioned we have competed the coding and almost throught with two phases of testing. Now turning back and modifying the code is out of testion due to the sheer amount of testing effort which will be involved.

Rob to answer your questionThe application presents the data for the users from ORACLE DB. Basically for every user request the appserver (using Stateless Session Beans) makes a call to the DB to get the data. This data is then put in a arraylist of value objects and passed to the client browser. The browser then renders the page from the data in the collection.

In essence for every user request we are creating the value objects and using the collection which in retrospect is a bad solution. But we have to live with it as thats all we have......

if that is the case then my reommendation is to use PerformaSure ....we use as part of our on going development and that might be able to tell you what is a bad java code or JDBC call...I hv been using this performasure tool for the last 9 months and it does give us some benefits

... The application currently in its testing phase is facing huge problems of screen response times. To this affect would apprciate any ideas by which we can improve the performance. ....What i am ideally looking at is that the solution sits on top of the already developed and tested application and does its job. Might sound to be a bit late in the cycle but thats what it is currently.

Rohit, you only have two choices:

1) Spend more time, trying to find out where is the bottlenecks that are below the performance problem, and fix the code (or the SQL sentences) that are facing bad response times.

2) Deploy the application and the database on stronger machines (more CPU and more memory).

Rohit, face it: if you have performance problems in your application, you must diagnose which SQL sentences are having worse response times, and fix them. When you finish with the SQL sentences, you must fix all the java code with poor response time (you are going to need to use some tool such as Quest PerformaSure).

If you cannot modify the SQL and the source code, then the only thing you can do to improve the response time is to buy more hardware. It sounds very hard, but it's the reality. Of course, when an application has a poor design, not always more hardware is the way to go, so I recommend to fix the code.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.