This is a design question on usage of beans. We are in the process of converting an old application to use J2EE technologies. Most of the required data for display is from servlets and we do not want to access servlets directly from jsp using scriplets. Is the only other alternative Beans ? If so, we are worried about storing so many bean objects in the session. Though we can restrict its availability to request, we may not be able to do it cos we need the data from one servlet across more than one jsp depending on the subsequent requests Can somebody point in the right direction to design the data exchange between servlets and jsp's across the session? Thanks RS
You're right to worry about carrying around a lot of data in your session (or request, for that matter) because you can really cause the memory needed to increase. However, have you looked at how much of this data you *really* need across the JSPs? Is this is a small amount then just going with a bean (or beans) may be OK. One thing we have done where I work is to break up the amount of data you get from a query and that is resident in a session at a time. This means more DB hits but compared to the network your DB hits are much less of a bottleneck. Another way (and this is what some servers do, WebSphere is an example) is that all that is carried around in the session is an ID and when data is needed the ID is used to retrieve it from the DB. Once again, you are trading of the DB hits vs storage in the session. This probably doesn't quite answer your question but hopefully gives you some things to think about. Maybe one of our gurus will swing by and give you some great advice! Good luck!
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
Can't .... do .... plaid .... So I did this tiny ad instead: