scriptlet processing query in JSP

[Viidhya Kishore]

Hello,
I am having a requirement from the client.

The requirement is :
I have a link.On clicking of the link,a session is opened for the user and I have to create a temp table for the current session.Then I have to insert data into it based on certain request parameters and then I need to select data from the temp table and display a table to the user.

Now,my question is:
If I do the table creation and population as well as select in a scriptlet tag (<% %>)
will the user be shown an empty page till the time the process gets done.
Because sometimes the select can take upto a min to get exeuted.

An approach from my side was : have a timer kind of a progress bar in the JSP,do all stuff in the <% %> tag and when the select has been executed,
hide the progress bar div and show the table div.

Any other way to do it?

Thanks,
Vidhya
[ July 24, 2008: Message edited by: Shriya Kishore ]

[Bear Bibeault]

Please be sure to take the time to compose descriptive subjects for your posts; read this for more information.

Using a title of "JSP issue" in a forum completely dedicated to questions on JSPs isn't very helpful.

You can go back and change your post to add a more meaningful subject by clicking the .

[Bear Bibeault]

Originally posted by Shriya Kishore:
Now,my question is:
If I do the table creation and population as well as select in a scriptlet tag (<% %>)
will the user be shown an empty page till the time the process gets done.
Because sometimes the select can take upto a min to get exeuted [sic].

Regardless of where you do a long-running server operation this will be true. Not just when you break accepted modern practices and put Java code in scriptlets on the page.

The tactic of putting up a "please wait" notice while the long process is running using JavaScript has been discussed many times.

You might also want to investigate sending less data to the page at a time. Is the amount of data you are sending really useful or required?
[ July 24, 2008: Message edited by: Bear Bibeault ]

[Viidhya Kishore]

yes it is.
I have to get the data to populate the report.

Any suggestions?

[Bear Bibeault]

Suggestions for what? You really haven't stated what you're looking for.

Are you unsatisfied with your current approach? If so, what do you want to change? What types of suggestions are you looking for?

[Viidhya Kishore]

ok....
I am currently having an asp report which is doing what I have stated above.
I need to replicate its functionality in JSP.

I would like to know if there is any other way of doing it apart from showing a progress bar and then hiding it to show the table of records.

Thanks

[Steve Luke]

First it would be best if you did the hard work in a Servlet or better another class you can run concurrent to the JSP (I know I am reiterating but it is the truth).

That said, you can set the JSP page's buffer to 0kb with:
<%@page buffer="none" %>
Then as you scroll through the result set you could immediately begin to populate the table for each row. After each row call <% out.flush() %> and you will get a table that grows rather than a blank page. You will still have some buffers to fill (proxies and IE itself has a buffer that must be filled before it first displays data) but you will get a quicker reaction.

[Bear Bibeault]

Adjust the buffer (which, as pointed out, may have limited effect). Show nothing. Show a stopwatch. Show a ticking time bomb. The question is, what do you want to see?

For long-running processes I will:

a) Make sure that I'm not forcing too much data on the user in the first place. Paging and filtering techniques loom large in this step.

b) If there is still a chance for a delay, I display a simple animation to let them know that somethings afoot (perhaps something like this):

Loading...

Note that many browsers will not show animations between page loads. That's one of the reasons I usually employ Ajax to make such requests.
[ July 24, 2008: Message edited by: Bear Bibeault ]

[Viidhya Kishore]

Hi Steve,
I am not quite understanding your approach though I find it appealing.

Can you please explain a little in detail?


Thanks,
Vidhya

[Steve Luke]

Originally posted by Shriya Kishore:
Hi Steve,
I am not quite understanding your approach though I find it appealing.

Can you please explain a little in detail?


Thanks,
Vidhya

Hmmm? I am just waiting for Bear's quote to finish loading, hold on a minute...

Oh wait, ....


Which approach do you want more info on? Using a concurrent class to read data (which I would prefer) or the zero buffer and constant flushing?

[Viidhya Kishore]

concurrent class as well as the zero buffer thing also.

I mean...I have never come across that so would like info on both of them.

Thanks a lot....

[Steve Luke]

The concurrent class method makes heavy use of the classes in java.util.concurrent. It starts by generating a runnable unit (in my example it will be a java.util.concurrent.Callable, but it could be a java.util.Runnable as well) that loads the data from the database.

In the runnable unit of code you will fill each row into a concurrent collection. The best to use is a form of java.util.concurrent.BlockingQueue where you want to wait for the next value(s) to be added rather than viewing snapshots of the database.

This runnable code is kicked off and run in a new Thread, and a Future object is used to monitor its progress.

Meanwhile, the JSP gets a reference to the BlockingQueue and retrieves values from it as soon as they become available and fills the page. It knows all the items are retrieved when the Future object says it is done.

So to kick it off, I have a DataTransportObject (DTO) which stores values for a single row on my table. This makes transport easy and understandable. In my example we will be getting a list of People from the DB so my DTO is called Person:

package luke.steven;
 
public class Person {
private String name, address, phone, id;

public String getName() {
return name;
}
public String getAddress() {
return address;
}
public String getPhone() {
return phone;
}
public String getId() {
return id;
}
public void setName(String name) {
this.name = name;
}
public void setAddress(String address) {
this.address = address;
}
public void setPhone(String phone) {
this.phone = phone;
}
public void setId(String id) {
this.id = id;
}
 
public Person() { }
}

I then have the interesting class. This is my DataAccessObject (DAO) which gets the People from a database. This is a really cut down version of a DAO but I wanted to just show you the important parts. This is the 'concurrent' class with the runnable block of code which does the work (this example it is public void call()). To run this class you do 3 steps:
1) Create a new instance of PersonGetter_DB
2) Call the getPeople() method to get a reference to the BlockingQueue of People
3) Call the startRetrievingData() method to begin the work and get a reference to the Future object for monitoring the progress

The code is as follows:

package luke.steven;
 
import java.sql.Connection;
import java.sql.ResultSet;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.LinkedBlockingQueue;
 
public class PersonGetter_DB implements Callable<BlockingQueue<Person>>{
private BlockingQueue<Person> people;

public PersonGetter_DB() {
people = new LinkedBlockingQueue<Person>(100);
}
 
/**
 * Does all the work for the database.  This method will be called in a new thread
 * allocated by an ExecutorService.  When the method finishes it returns the completed
 * Queue of all the people retrieved from the DB
 * 
 * You should not iterate over the BlockingQueue returned by call, or returned by
 * the Future object monitoring this call.  If properly consumed the Queue will be
 * empty, and if not there will be no clear sign as to when to stop iterating.
 * 
 * @return A BlockingQueue (completed) of all the contents in the DB.  To iterate over
 * the BlockingQueue use the toArray method, though if properly consumed the Queue will
 * be empty.
 */
@Override public BlockingQueue<Person> call() throws Exception {
Connection conn = getConnection();
ResultSet rs = getAllUsers(conn);
while (rs.next()) {
Person p = new Person();
p.setId(rs.getString("id"));
p.setName(rs.getString("name"));
p.setAddress(rs.getString("address"));
p.setPhone(rs.getString("phone"));
people.put(p);
}

closeResults(rs);
closeConnection(conn);
return people;
}

/**
 * Retrieves the Queue of people.  The Queue may be empty when the the list is first
 * retrieved and trying to iterate over it will block until the first object is added.
 * @return A BlockingQueue of people retrieved from the DB
 */
public BlockingQueue<Person> getPeople() {
return people;
}

/**
 * Starts a new thread where the list of people will be generated and returns a
 * Future object which can be used to monitor the task. 
 * @return A Future whose isDone() method returns true when all rows are retrieved.
 */
public Future<BlockingQueue<Person>> startRetrievingData() {
ExecutorService service = Executors.newSingleThreadExecutor();
Future<BlockingQueue<Person>> monitor = service.submit(this);
return monitor;
}

private Connection getConnection() {
Connection conn = null;
//get connection to DB
return conn;
}
private void closeConnection(Connection conn) {
try {
conn.close();
} catch (Exception e) {
//close silently
}
}
private ResultSet getAllUsers(Connection conn) {
ResultSet rs = null;
//run query
return rs;
}
private void closeResults(ResultSet rs) {
try {
rs.close();
} catch (Exception e) {
//close silently
}
}

}

That is a lot of code, sorry... One last bit though, the JSP. The JSP in this case will create a new PersonGetter_DB object using the jsp:useBean tag. It then uses scriptlets to call the other two methods and to start a while loop which checks the Future object (monitor) to see if the DB is done. In the while loop it populates the table.

Here is the code:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" buffer="none"
    pageEncoding="ISO-8859-1" import="java.util.concurrent.BlockingQueue" 
    import="java.util.concurrent.Future" import="luke.steven.Person" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>List of a lot of people</title>
</head>
<body>
  <h2>Look at all these people</h2>
  <table>
    <thead>
      <tr><th>ID</th><th>Name</th><th>Address</th><th>Phone</th></tr>
    </thead>
    <tbody>
      <jsp:useBean id="peopleGetter" class="luke.steven.PersonGetter_DB" scope="page"/>
      <% BlockingQueue<Person> people = peopleGetter.getPeople();
         Future<BlockingQueue<Person>> monitor = peopleGetter.startRetrievingData();
         while (!monitor.isDone()) {
         Person person = people.take();
      %>
  <tr>
          <td><%= person.getId()%></td><td><%= person.getName()%></td>
          <td><%= person.getAddress()%></td><td><%= person.getPhone()%></td>
      </tr>
      <% out.flush();
         } 
      %>
    </tbody>
  </table>
</body>
</html>

Note that this JSP has the buffer="none" attribute for the page directive, and flushes the output after each loop, so it is pretty much both options I suggested earlier. I like this better because most of your work occurs outside the JSP which makes it easier to code, test, and debug (both the JSP and the DB access code).

I would like to fill most of the scriptlets with JSTL and EL if I could, and if I designed the DAO slightly better I could do pretty well, but there is no JSTL while loop that I am aware of, and using the Queues iterator in a forEach loop wouldn't work so well (would block forever at the end). Given a little motivation you could put this all into a custom tag and be done with all the scriptlets, but until then ...

Anyway, this isn't a definitive answer for a DataAccessObject. But it is a pretty good addition to one I think. You should search the net for Java DataAccessObject, there are good examples in a lot of places (for example look up BalusC's blog, he has a good one)
[ July 24, 2008: Message edited by: Steve Luke ]

[Viidhya Kishore]

Thanks a lot for the really detailed solution.

I really appreciate your effort to help.

Will look into it more in detail and repost if any issues.

Thanks once again.

Vidhya