You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Marko Asplund <as...@kronodoc.fi> on 2001/11/11 20:37:07 UTC
non-serializable objects in sessions
how should non-serializable objects be stored in HttpSessions? i'd like to
be able to use the PersistentManager for storing the serializable objects
inside sessions while skipping the non-serializable objects like database
statement handles. how can this be accomplished with Tomcat v4.0.1?
--
aspa
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by Tom Drake <rt...@pobox.com>.
Aspa:
Tomcat uses serialization as the means to 'persist' Session data.
The answer to your question is to make any objects that you wish to
persist implement java.io.Serializable. This is easy enough as long as
you have the source code. If you don't have the source code, then
you'll need to create a wrapper class for each of the non-serializable
objects you wish to store in your persistant sessions. The wrapper
classes must be serializable, and must contain enough data to recreate
the non-serializeable objects.
Tom Drake
----- Original Message -----
From: "Marko Asplund" <as...@kronodoc.fi>
To: <to...@jakarta.apache.org>
Sent: Sunday, November 11, 2001 11:37 AM
Subject: non-serializable objects in sessions
|
| how should non-serializable objects be stored in HttpSessions? i'd like to
| be able to use the PersistentManager for storing the serializable objects
| inside sessions while skipping the non-serializable objects like database
| statement handles. how can this be accomplished with Tomcat v4.0.1?
|
| --
| aspa
|
|
| --
| To unsubscribe: <ma...@jakarta.apache.org>
| For additional commands: <ma...@jakarta.apache.org>
| Troubles with the list: <ma...@jakarta.apache.org>
|
|
|
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by Tom Drake <rt...@pobox.com>.
Glad to help
----- Original Message -----
From: "Marko Asplund" <as...@kronodoc.fi>
To: "Tomcat Users List" <to...@jakarta.apache.org>
Sent: Tuesday, November 13, 2001 3:40 AM
Subject: Re: non-serializable objects in sessions
|
| thanks for pointing out the database resource consumption problem!
|
| i'll probably define an upper limit for result rows shown to the user in
| my application. then i'll use one query to get all the object ids of the
| result objects, store them (instead of the ResultSet) in the user's
| session. then the object data can be fetched from the database
| "page-by-page" as the user browses through the list of result objects.
|
| best regards,
| --
| aspa
|
|
|
| --
| To unsubscribe: <ma...@jakarta.apache.org>
| For additional commands: <ma...@jakarta.apache.org>
| Troubles with the list: <ma...@jakarta.apache.org>
|
|
|
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by David Cassidy <dc...@hotgen.com>.
Make sure that when the user leaves that area of the site
you remove the result objects from the users session.
Otherwise your memory consumption could go up
rather quickly !!!
Marko Asplund wrote:
> thanks for pointing out the database resource consumption problem!
>
> i'll probably define an upper limit for result rows shown to the user
> in
> my application. then i'll use one query to get all the object ids of
> the
> result objects, store them (instead of the ResultSet) in the user's
> session. then the object data can be fetched from the database
> "page-by-page" as the user browses through the list of result objects.
>
> best regards,
> --
> aspa
>
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by Marko Asplund <as...@kronodoc.fi>.
thanks for pointing out the database resource consumption problem!
i'll probably define an upper limit for result rows shown to the user in
my application. then i'll use one query to get all the object ids of the
result objects, store them (instead of the ResultSet) in the user's
session. then the object data can be fetched from the database
"page-by-page" as the user browses through the list of result objects.
best regards,
--
aspa
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by Tom Drake <rt...@pobox.com>.
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" <as...@kronodoc.fi>
To: "Tomcat Users List" <to...@jakarta.apache.org>
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: <ma...@jakarta.apache.org>
| For additional commands: <ma...@jakarta.apache.org>
| Troubles with the list: <ma...@jakarta.apache.org>
|
|
|
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 12 Nov 2001, Marko Asplund wrote:
> Date: Mon, 12 Nov 2001 20:49:19 +0200 (EET)
> From: Marko Asplund <as...@kronodoc.fi>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by Marko Asplund <as...@kronodoc.fi>.
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: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: non-serializable objects in sessions
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 11 Nov 2001, Marko Asplund wrote:
> Date: Sun, 11 Nov 2001 21:37:07 +0200 (EET)
> From: Marko Asplund <as...@kronodoc.fi>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: non-serializable objects in sessions
>
>
> how should non-serializable objects be stored in HttpSessions? i'd like to
> be able to use the PersistentManager for storing the serializable objects
> inside sessions while skipping the non-serializable objects like database
> statement handles. how can this be accomplished with Tomcat v4.0.1?
>
It can't.
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.
If you need persistence, you have to be aware of what can and cannot be
persisted. It's possible that Enterprise JavaBeans (EJBs) might be a
better solution to the types of problems you are looking at, because they
deal with low level persistence issues for you.
> --
> aspa
>
Craig McClanahan
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>