> -----Original Message----- > From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 08:37 > To: Struts Users Mailing List > Subject: RE: some best practices questions > > > People seem to treat using the session as though it were some > kind of moral > sin. > > There are technical pros and cons to using the session and > these should be > considered when you do your coding, but the session scope is > not harem. You > wont be cursed with eternal damnation because you shove a > couple of dropdown > lists in the session for a while. It just has implications for > performance/scalabilty in certain situations that mean that > avoiding its use > is often advantageous. (Such as the posibilty that "a while" > could translate > to "until the session times out", and that if your in a clustered > environment the container may need to serialise the session > around between > machines quite often) >
Usually those considerations are due to the fears that the host machine or application will crash with a very high volume of simultaneous users. For example it is not a good idea to store large bitmapped images, say from a 5.0mega pixel digital camera in a HttpSession directly or indirectly for each web user. You are asking for trouble if you suddenly architect a load balancing solution. > Doing 'wierd stuff' (tm) in application scope or on the file > system in an > effort to reproduce the effect of a session seems a bit dodgy > to me (ie: > surely the container is far better at implementing sessions > than you are!). > Now if its because you have thought it through carefully and > logically and > that in this case it really is better to do it this way then thats a > different matter, but if its just due to some instinctive ideological > aversion to using the session api, well thats just nuts. > Having said that you probably want to use a generic caching solution, basically any lease-time based cache that uses a map collection behind the scenes to cache images in my digital photostore example. You would put a global image cache in the application scope (Servlet Scope) and then all of the web application can access the cache. Also you would set an expiration time to be greater than 30 minutes or higher than the session timeout, or what is the point> I can see a place for lease time cache (LRU or otherwise) that sits between the HttpSession (30 mins by default) and the application scope (infinite or until the web container / server is restarted or die) > For this particular use case I would either just use the session, or > alternatively I would just look up the dropdowns from db each time and > accept the performance hit, but its (probably) not worth the > development > time - including ongoing maintenance - to do anything overly > tricky just for > a few dropdowns. > Alternatively behind the scenes put the cache in the DAO layer or services layer. You can also rely on the OR/M framework to do this for you if it is intelligent to cache similar queries and result sets. > my 2c > -Andrew > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, 8 July 2004 13:09 > To: [EMAIL PROTECTED] > Subject: RE: some best practices questions > > > I think, performance wise File I/O is not the right idea. > > What do you say ? > > -----Original Message----- > From: Christina Siena [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 08, 2004 8:16 AM > To: Struts Users Mailing List > Subject: Re: some best practices questions > > I have an idea how to persist the data that I currently place > in session > scope but I need to run it by someone. > > Recall when I said that placing data in session scope is > frowned upon by > some members of my team? Well no one said anything about not > using Java > serialization. Why couldn't I serialize the > same data that I currently keep in session scope? I've already > implemented a solution for streaming images so creating a temp file > should not be a problem. Here is what I think I will need: > > In the action where the data is first retrieved: > > try { > final String prefix = "myVehicleLineMap"; > final String suffix = null; > File file = File.createTempFile(prefix, suffix); > FileOutputStream fileOutputStream = new FileOutputStream(file); > ObjectOutputStream objectOutputStream = new > ObjectOutputStream(fileOutputStream); > objectOutputStream.writeObject(myMap); > objectOutputStream.flush(); > myForm.setTempFileName(file.getAbsolutePath()); > } catch (Exception e) { > System.out.println(this.getClass().getName() + "==>> " + > e.toString()); > } > > In the action where the data needs to be re-accessed to > prepare the page > for re-display: > > try { > > FileInputStream fileInputStream = new > FileInputStream(myForm.getTempFileName()); > ObjectInputStream objectInputStream = new > ObjectInputStream(fileInputStream); > SortedMap myMap = (SortedMap) objectInputStream.readObject(); > // use myMap as before (when in session scope) > } catch (Exception e) { > System.out.println(this.getClass().getName() + "==>> " + > e.toString()); > } > > This is just an idea at this point, so I would welcome any > feedback. I'm > not sure if this will work or if its feasible, but at least it may > generate some more ideas. > > ----- Original Message ----- > From: Michael McGrady > To: Struts Users Mailing List > Sent: Tuesday, July 06, 2004 11:59 PM > Subject: Re: some best practices questions > > > Ever thought about creating a new scope managed by your own manager > from > application scope? That is an approach I have been thinking of more > and > more as of late. > > At 08:35 PM 7/6/2004, you wrote: > >I used hidden select lists to restore user selections > since I wasn't > >"allowed" to place the whole form in session scope. The > >management/maintenance of user selections was indeed ugly (but its > done > >and works fine). My question has to do with the data retrieved from > the db > >(from which the user makes selections). For example, when > the form is > > >initially displayed, I populate a list of vehicle lines > (i.e. Focus, > >Mustang, Freestar, and so on). The user can copy a vehicle > line from > the > >source list to the target list. The target list consists of user > >selections. When the page needs to be re-displayed as a result of > some > >other query, I needed to re-populate the list of vehicle lines (the > source > >list). I felt that re-retrieving the same vehicle lines from the db > again > >was silly (since I got it once I simply put a map in > session and use > it > >when needed). When posting the form, the list of label > value beans is > no > >longer available in the action, so my options were: (1) > either store > in > >hidden lists (concatenating the key with the description) or (2) > >re-retrieve the vehicle lines from the db or (3) place them in > session the > >first they are retrieved and get them from session scope. > I chose the > > >third and wondered about some best practices others have used in > similar > >situations. > > ----- Original Message ----- > > From: Rick Reumann > > To: Struts Users Mailing List > > Sent: Tuesday, July 06, 2004 10:58 PM > > Subject: Re: some best practices questions > > > > > > Christina Siena wrote: > > > > > I recently developed an application with a complex UI. One of > the > > > pages required querying the database based on user > selection and > > > re-displaying the page with the retrieved data and > any previous > > > existing user selections. Four different fields can > trigger a db > > > query resulting in page re-display and validations can also > result in > > > page re-display. Each time the page is re-displayed, > the "state" > of > > > the page must be "remembered" from the last time it was > displayed. > > > (still with me so far?) Most of the data retrieved is > list data > > > displayed in single- or multi-select lists and populated using > > > html:options collection and LabelValueBean. (for those of you > reading > > > this post who have developed similar code, you will know what > I'm > > > referring to). > > > > > > In the action, the retrieved data is placed in > session scope to > > > minimize db hits. I thought this was a good idea at the time. > For > > > some reason, placing data in session scope is frowned upon by > some > > > members of my team (even if improves performance). > Anyways, what > I > > > need are some ideas of the best practices that fellow Struts > users > > > follow when a page requires querying the db and re-displaying > the > > > page with the retrieved data and previous selections > if placing > the > > > data in session scope is not an option. How can I recall the > > > previously retrieved data without requerying the db? Would it > make > > > sense to hide the data in the page? (i.e. either using hidden > fields > > > or hidden select lists or to generate a JavaScript > array). What > are > > > the risks, if any, of hiding the data in the page? (i.e. > > > performance). > > > > > > If anyone has developed similar pages, can you tell me if you > decided > > > for or against placing data in session scope and why? > > > > Here's is my 2cents. Personally I'm not as anti-session as most > people, > > and I think to use it or not use has to be taken on a case per > case > > basis. If your queries to generate the lists are not going be > cached in > > anyway by the backend and/or they are expensive queries to run, > the > > Session can be a better place to temporarilly store this > information as > > the user progresses through the 'flow' as you've > described above. > Sure > > the data each time might not be perfectly fresh, so if that is a > > requirement than you will need to query after each new selection > is > > chosen. I'd opt for testing out performance making a new query > each time > > to generate your lists for the drop downs and see how > it behaves. > (If > > your data in the database will never be altered by an external > process > > you can really leverage something like iBATIS that will cache > queries > > for you so everything is golden). > > > > You are asking a two part question, though, and one > thing I think > that > > you 'might' be confusing is the use of the lists in > Session versus > the > > ActionForm in Session (retaining user's selections). > From what you > are > > describing I would DEFIINITELY keep your form bean in Session > scope for > > this. This way any chosen parameters will be remembered > as you are > > brought back to the page. This is a perfectly legit use of the > Session > > and don't let anyone convince you in to using a bunch of hidden > > variables and storing your form bean in request scope each time. > (To me > > that is so stupid, how much memory is a Form bean going > to take up > in > > Session scope weighed out agains the ugliness and maintenance of > dealing > > with a bunch of hidden variables and making sure they are always > set > > etc. USE the Session in this case for you form bean). You are > basically > > describing in a sense a "wizard" where the user might be brought > along > > to different pages to collect data in a form, only you > are simply > > reusing the same form with different lists. > > > > -- > > Rick > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > If you can -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44 (0)207 883 4447 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
