Doing what you're attempting is extremely dangerous. You are very likely to start 'leaking' database connections this way. Suppose 10 users were to each perform one of these queries, but never ask to see the '2nd page' of results. Let's say that the session timeout is 30 minutes. That means all ten database connections will be unavailable for anyone to use for at least 30 minutes. This assumes that you are using connection pooling or are careful to 'clean-up' these connections in your object finalization.
There is a limit to the number of database connections that your database supports. Sometimes there is a hard-limit, sometimes the limit is configurable (e.g. Oracle), sometimes the limit is simply dependant on system resources. BTW, Oracle imposes a connection limit of 50 by default. You can change this. Using the method of 'hanging' onto these partially completed queries you will certainly burn database connections. You have, at least two other options: 1) Write your bean in such a way that it fetches the result set data into a local collection. If your result sets tend to be quite large, then you may need to do the fetching in a separate thread. When your bean figures out that there is a 'page' of data, or that fetching is complete, it can return the 1st available page of data to the client. The disadvantage of this approach is for really 'huge' queries (e.g. thousands of rows). Of course, you can easily alter your UI to allow the users to constrain their own queries (e.g. 1st 10, 50, 100, 200, 500, 1000 results). If your users typically return many hundreds or thousands of 'matches', You may need to rethink your design anyway, since the usefulness of such a large amount of data is dubious at best. This is arguably the easier of these two methods to write. However, it may result in more database activity, than is necessary, if your users don't typically page thru all of the results. 2) Have each 'page' of results result in a separate query to the database. Each query would have to be constrained or filtered in such a way as to produce the 'next' page of data. If your results are sorted in any way, You may be able to constrain the query by some combination of the sorted columns. (e.g. if the last Product ID displayed on the 1st page was 'abc123', the query for the second page might be 'select * from product where productid > 'abc123' order by productid'). Good Luck Tom Drake ----- Original Message ----- From: "Marko Asplund" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 10:49 AM Subject: Re: non-serializable objects in sessions | On Sun, 11 Nov 2001, Craig R. McClanahan wrote: | | > ... | > There is no way in Java to persist a non-Serializable object like a | > database statement. In fact, you cannot even use such a thing if you're | > using a connection pool (completely separate from session persistance | > issues) unless the connection pool itself implements support for this. | | what i'd like to do is store Statement and ResultSet objects in a user | session so, that the data fetched from the database can be paginated more | easily for the user. these objects don't have to be persistent, but when | Tomcat is shut down it automatically tries to serialize the contents of | user sessions. when this happens i get warnings about the non-serializable | objects. i'd like to make these warnings go away. should i just put these | objects inside another class designed to store query state and implement | the Serializable interface (no serialization, just close handles) in this | class? are there any additional issues to take into consideration when | storing Statement and ResultSet objects inside sessions? | | -- | aspa | | | -- | To unsubscribe: <mailto:[EMAIL PROTECTED]> | For additional commands: <mailto:[EMAIL PROTECTED]> | Troubles with the list: <mailto:[EMAIL PROTECTED]> | | | -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
