Originally posted by Desai Sandeep:
We had a very simple requirement to pass the Resultset Object, which was obtained by one of the methods of the Java Bean.
It is bad practice to allow "live", connected ResultSet objects to venture anywhere outside a try... finally block. If you must, use a disconnected buffer such as a Collection or a javax.sql.CachedRowSet.
There certainly cannot be any question of passing a ResultSet between JVMs, let alone between a server and a browser and back. Even if a ResultSet were Serializable -- it is not -- all the state of the database connection would be transient, and lost upon deserializing the ResultSet.
- Process the Resultset in first JSP itself.
- Use the setAttribute() of request,session or application implicit objects, as Maha anna has suggested

- Pass the Resultset object to another JSP along with the form fields.
The first option is preferable by far. The second works, but violates good practice as indicated above, because (a) it is a potential source of resource leaks (b) hogs a database connection for longer than necessary and (c) couples two separate Java classes (the JSPs) much too tightly. The third is impossible.
There is a fourth option -- refactoring. I don't know the details, but it sounds as if there is something fundamentally flawed about what you want to do. If your first JSP is about setting up a data query, then it should not be a JSP but a combination of a servlet and Java classes, JavaBeans, or EJBs. For example, instead of passing an open query from one JSP to the other, you could pass a request- or session-scoped
query object that contains enough information and code to run the query the moment you need the data. This addresses all concerns mentioned above in one go: (a) since you delay firing the query until you actually need the data, you can protect it with a try... finally block (b) for the same reason, the connection is used as briefly as possible and (c) the query object acts as a well-defined interface between the two jsps/servlets
and moves all the database access code out of them.
This is just one possible solution. There are at least half a dozen others (such as using a session EJB to hold the query state and provide a facade for the data access).
- Peter