On Mon, 12 Nov 2001, Marko Asplund wrote:
> Date: Mon, 12 Nov 2001 20:49:19 +0200 (EET)
> From: Marko Asplund <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> 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?
>
Whether or not you can serialize Statement and ResultSet objects is up to
your JDBC driver, and has nothing to do with Tomcat. However, I would not
hold my breath -- for example, many JDBC drivers maintain a network
connection (i.e. a java.net.Socket) to the underlying database, and this
will never be Serializable.
You're going to have an additional problem with your approach, even if you
don't worry about serialization. Keeping a PreparedStatement or ResultSet
means you need to keep the Connection from which they are created as well,
and not let it be reused by other users. Thus, you're going to get almost
no benefit from the connection pool itself.
I would suggest that you think carefully about whether the potential
performance benefit from keeping prepared statements around is worth the
cost.
> --
> aspa
>
Craig McClanahan
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
