Scroll to End on the Web for big tables.

We have a request from some of our users to open ‘Go To End’ (Scroll to End) functionally on some of the applications. Right now it is closed by default.

From my experience ‘scroll to end’ can significantly affect performance on the large amount of data. One time I have even observed Websphere crash when user fetched about 20000 records from one of the applications. It wasn’t a production server though.
It is my understanding that Web server caches entire table when Go-to-End is invoked.

We don’t have problems with grids that will have few hundred records, but one particular application worries me a lot – it’s an Employee master (P0801) with 5000+ records. Users say that they would like to perform ‘group operations’ by selecting multiple users the same time.
And do it on a regular basis.

So far we have been able to live without ‘Go-to-end’ for regular users in other E1 modules. Users have been trained to do proper filtering to reduce the number of records that they have to deal with.
Apparently it doesn’t seem to be satisfying with HR 

I am wondering what is everyone’s experience with ‘Go to End’ option in general and with 5000 records volume in P0801 application in particular.

We have performed some tests in DV environment and they show significant CPU load (up to 90% of one CPU) on WAS server when doing ‘Go-to-End’ on tables with 5000-10000 records.

Thanks !

E1 8.11SP1 8.95_O1
AIX 5.3 / Oracle 9.2
WAS 5.0.2 on Windows 2003 server.

PS We have also tried this solution, but it didn’t change things a lot
http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=200972848

The recommendations around the lock down of scroll to end when using WAS come from the fact that the grid lines are not freed from memory since these are "complex" objects. This ALWAYS will eventually result in running out of Java Heap memory - it's just a matter of time. The issue in my opinion is a IBM issue however IBM says "well that's how it works" and indicates that it's a JDE issue.

Regardless JDE has changed their code to work around the problem.

The code fix is in 8.96.1.4 and the SAR is 8488485.

Once you're on this Tools Release then it's simply a business decision (as opposed to technical).