Originally posted by William Brogden:
The session is provided for that purpose. There is no limit built in to the API on the number of objects or size of objects attached to a session.
IMHO - Ack!
Any data written to the session is persisted until the session is destroyed. If you do something like this for every user logged in, it doesn't take long for the server to choke. If you try to manage reading/writing and erasing data on the session it is still a nightmare due to the non-linear nature of web apps (jumpimg back 10 pages, for example)
This is just my opinion, but if you need an object between different requests either retrieve it again or serialise it on the page as a hidden field or something (I don't like this option either)
As a third option you could organise your own server side object cache so that the caching strategy is separate to the session so that it can be set to have a much shorter lifetime than the session object.
Dave, I totally agree with you on not putting it in the session. This is a relativly large object whose scope is only between one JSP page and one servlet. It seems to me that I should be able to tack the Vector onto the request object being sent to the servlet. I am having a hard time understanding if this is possible, but doing so would certainly accomplish my goal of a limited life/scope method of trasnfering objects. The hidden field is possible, but I would rather take advantage of the Java language available to me.
Thanks for everyones help.
Originally posted by Tony Alicea:
"serialise it on the page as a hidden field or something"
How do you do that?
Make the class Serializable (if it isn't already) get the byte array representation of the stream, Base64Encode it so it can be written on the page then put it in the page as a hidden field.
When the page gets re-submitted you can reverse the process.
I'll just repeat that this isn't a solution I like but it is another valid solution to the problem.