RE: some best practices questions
Just in continuation to discussion, as Peter says, My comment would be that *data* caching should be done in the data layer > (like I would like to make small comment on the same, Data Caching should be keeping in mind that kind of data we need to cache. If cached data is of presentation specific (like rendering drop downs etc), caching at presentation layer (in servlet context ) would be just fine. But if it is of back end processing type (i.e. Currency Exchange Rate etc), it will be advisable to maintain at data layer. - regards Raj (+91-11-31261821) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 9:15 AM To: Struts Users Mailing List Subject: Re: some best practices questions One of our application had more than 300 screens, we used struts and most of those screens had a drop-down list. We stored all of them in servlet context, and every JSP got a copy of it in "pre-populate place holder". The peak user load was abt 500, and its working just fine...!!! Regards, Puneet Agarwal Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Mike Duffy <[EMAIL PROTECTED]> 07/19/2004 11:14 PM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To Struts Users Mailing List <[EMAIL PROTECTED]> cc Subject Re: some best practices questions What do you think of caching static or semi-static data that applies to all users (options in a drop down list, etc.) in the application scope? --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > My comment would be that *data* caching should be done in the data layer > (like ibatis, hibrenate, whatever). > .V > > Pilgrim, Peter wrote: > >>-Original Message- > >>From: Michael McGrady [mailto:[EMAIL PROTECTED] > >>Sent: 08 July 2004 09:14 > >>To: Struts Users Mailing List > >>Subject: RE: some best practices questions > >> > >> > >>At 12:36 AM 7/8/2004, you wrote: > >> > >>>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. > >>> > >>>my 2c > >> > >>The thing is, though, Andrew, these are recurrent issues and seem to > >>require a generic solution. Having a small manager in > >>application scope > >>which can create and monitor a scope which is not > >>application, not session, > >>and not request, is worth the while for these recurrent problems, I > >>think. The persistence of such a scope can be made a > >>function of the data > >>rather than the interest of the clients. That is worth > >>having to use on a > >>general basis, I think, and can be done with a very small performance > >>hit. In fact, my guess is that it would be a performance plus. > >> > >>Michael > >> > >> > >> > > > > > > Well this is astounding, because I looking at JCache JSR whatever? > > and looking at alternatives like OSCache for a caching the look up > > of login user accounts. So where the hell is JCache or the standard. > > > > If it was there, I think it would give you what you want? > > > > -- > > 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] > > __
Re: some best practices questions
One of our application had more than 300 screens, we used struts and most of those screens had a drop-down list. We stored all of them in servlet context, and every JSP got a copy of it in "pre-populate place holder". The peak user load was abt 500, and its working just fine...!!! Regards, Puneet Agarwal Tata Consultancy Services Mailto: [EMAIL PROTECTED] Website: http://www.tcs.com Mike Duffy <[EMAIL PROTECTED]> 07/19/2004 11:14 PM Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To Struts Users Mailing List <[EMAIL PROTECTED]> cc Subject Re: some best practices questions What do you think of caching static or semi-static data that applies to all users (options in a drop down list, etc.) in the application scope? --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > My comment would be that *data* caching should be done in the data layer > (like ibatis, hibrenate, whatever). > .V > > Pilgrim, Peter wrote: > >>-Original Message- > >>From: Michael McGrady [mailto:[EMAIL PROTECTED] > >>Sent: 08 July 2004 09:14 > >>To: Struts Users Mailing List > >>Subject: RE: some best practices questions > >> > >> > >>At 12:36 AM 7/8/2004, you wrote: > >> > >>>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. > >>> > >>>my 2c > >> > >>The thing is, though, Andrew, these are recurrent issues and seem to > >>require a generic solution. Having a small manager in > >>application scope > >>which can create and monitor a scope which is not > >>application, not session, > >>and not request, is worth the while for these recurrent problems, I > >>think. The persistence of such a scope can be made a > >>function of the data > >>rather than the interest of the clients. That is worth > >>having to use on a > >>general basis, I think, and can be done with a very small performance > >>hit. In fact, my guess is that it would be a performance plus. > >> > >>Michael > >> > >> > >> > > > > > > Well this is astounding, because I looking at JCache JSR whatever? > > and looking at alternatives like OSCache for a caching the look up > > of login user accounts. So where the hell is JCache or the standard. > > > > If it was there, I think it would give you what you want? > > > > -- > > 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] > > __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ForwardSourceID:NT23F6 DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read
RE: some best practices questions
> -Original Message- > From: Mike Duffy [mailto:[EMAIL PROTECTED] > Sent: Monday, July 19, 2004 10:45 AM > To: Struts Users Mailing List > Subject: Re: some best practices questions > > > What do you think of caching static or semi-static data that > applies to all users (options in a > drop down list, etc.) in the application scope? I think it depends on how much memory all your ddl and other type stuff is. That's what application scope is for, anythinng that should be application wide. > > --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > > My comment would be that *data* caching should be done in > the data layer > > (like ibatis, hibrenate, whatever). > > .V > > > > Pilgrim, Peter wrote: > > >>-Original Message- > > >>From: Michael McGrady [mailto:[EMAIL PROTECTED] > > >>Sent: 08 July 2004 09:14 > > >>To: Struts Users Mailing List > > >>Subject: RE: some best practices questions > > >> > > >> > > >>At 12:36 AM 7/8/2004, you wrote: > > >> > > >>>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. > > >>> > > >>>my 2c > > >> > > >>The thing is, though, Andrew, these are recurrent issues > and seem to > > >>require a generic solution. Having a small manager in > > >>application scope > > >>which can create and monitor a scope which is not > > >>application, not session, > > >>and not request, is worth the while for these recurrent > problems, I > > >>think. The persistence of such a scope can be made a > > >>function of the data > > >>rather than the interest of the clients. That is worth > > >>having to use on a > > >>general basis, I think, and can be done with a very small > performance > > >>hit. In fact, my guess is that it would be a performance plus. > > >> > > >>Michael > > >> > > >> > > >> > > > > > > > > > Well this is astounding, because I looking at JCache JSR whatever? > > > and looking at alternatives like OSCache for a caching the look up > > > of login user accounts. So where the hell is JCache or > the standard. > > > > > > If it was there, I think it would give you what you want? > > > > > > -- > > > 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] > > > > > > > > > > __ > Do you Yahoo!? > New and Improved Yahoo! Mail - 100MB free storage! > http://promotions.yahoo.com/new_mail > > - > 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]
Re: some best practices questions
What do you think of caching static or semi-static data that applies to all users (options in a drop down list, etc.) in the application scope? --- Vic Cekvenich <[EMAIL PROTECTED]> wrote: > My comment would be that *data* caching should be done in the data layer > (like ibatis, hibrenate, whatever). > .V > > Pilgrim, Peter wrote: > >>-Original Message- > >>From: Michael McGrady [mailto:[EMAIL PROTECTED] > >>Sent: 08 July 2004 09:14 > >>To: Struts Users Mailing List > >>Subject: RE: some best practices questions > >> > >> > >>At 12:36 AM 7/8/2004, you wrote: > >> > >>>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. > >>> > >>>my 2c > >> > >>The thing is, though, Andrew, these are recurrent issues and seem to > >>require a generic solution. Having a small manager in > >>application scope > >>which can create and monitor a scope which is not > >>application, not session, > >>and not request, is worth the while for these recurrent problems, I > >>think. The persistence of such a scope can be made a > >>function of the data > >>rather than the interest of the clients. That is worth > >>having to use on a > >>general basis, I think, and can be done with a very small performance > >>hit. In fact, my guess is that it would be a performance plus. > >> > >>Michael > >> > >> > >> > > > > > > Well this is astounding, because I looking at JCache JSR whatever? > > and looking at alternatives like OSCache for a caching the look up > > of login user accounts. So where the hell is JCache or the standard. > > > > If it was there, I think it would give you what you want? > > > > -- > > 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] > > __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some best practices questions
My comment would be that *data* caching should be done in the data layer (like ibatis, hibrenate, whatever). .V Pilgrim, Peter wrote: -Original Message- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 09:14 To: Struts Users Mailing List Subject: RE: some best practices questions At 12:36 AM 7/8/2004, you wrote: 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. my 2c The thing is, though, Andrew, these are recurrent issues and seem to require a generic solution. Having a small manager in application scope which can create and monitor a scope which is not application, not session, and not request, is worth the while for these recurrent problems, I think. The persistence of such a scope can be made a function of the data rather than the interest of the clients. That is worth having to use on a general basis, I think, and can be done with a very small performance hit. In fact, my guess is that it would be a performance plus. Michael Well this is astounding, because I looking at JCache JSR whatever? and looking at alternatives like OSCache for a caching the look up of login user accounts. So where the hell is JCache or the standard. If it was there, I think it would give you what you want? -- 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]
RE: some best practices questions
> -Original Message- > From: Michael McGrady [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 09:14 > To: Struts Users Mailing List > Subject: RE: some best practices questions > > > At 12:36 AM 7/8/2004, you wrote: > >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. > > > >my 2c > > The thing is, though, Andrew, these are recurrent issues and seem to > require a generic solution. Having a small manager in > application scope > which can create and monitor a scope which is not > application, not session, > and not request, is worth the while for these recurrent problems, I > think. The persistence of such a scope can be made a > function of the data > rather than the interest of the clients. That is worth > having to use on a > general basis, I think, and can be done with a very small performance > hit. In fact, my guess is that it would be a performance plus. > > Michael > > > Well this is astounding, because I looking at JCache JSR whatever? and looking at alternatives like OSCache for a caching the look up of login user accounts. So where the hell is JCache or the standard. If it was there, I think it would give you what you want? -- 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]
RE: some best practices questions
> -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() + "==>>
RE: some best practices questions
My understanding (could be wrong on this of course) was that if you dont have sticky sessions the container has to serialise the session to its brethren as necessary. The serialisation is what scares most people, but what scares me is how it knows when and what to serialise (plus the fact it stops you using non-serialisable stuff!) I gather many (all?) containers listen for calls to the session.setAttribute() to determine when session contents have changed, however when the modification is in some object that is 50 levels deep inside some wierd structure that is being modified by something that knows nothing (and should not know anything) of the session API... well thats a nightmare! So if you give up the ability to do that kind of thing you basically give up the potential for doing anything non-trivial in your application at the presentation tier. Probably not a problem for the millions writing shopping carts, but for this rest of us who are trying to write real applications for which the GUI requirements are painful enough in a rich client never mind on the web... :-( Non-sticky sessions just arent practical. (I guess this is what Michael was trying to tell me yesterday in regards to needing a new scope!) Luckily for complex apps one isnt (usually) talking tens of thousands of simultaneous client logins, and the rare loss of a client session is mainly an annoyance and so long as they can log back in again and so long as the business layer keeps going its usually ok (in these cases its usually the business layer that does all the work and the UI is mostly for administration of it). For shopping carts of course, a lost session is a lost order, and there are vast number of potential users so the need for failover and load balancing is quite genuine... -Original Message- From: McCormack, Chris [mailto:[EMAIL PROTECTED] Sent: Thursday, 8 July 2004 22:37 To: Struts Users Mailing List Subject: RE: some best practices questions >users will fail over to another box with nothing in their session. In some applications this is an acceptable risk if you have high uptime servers and very few code releases. If you however want a solid insurable "customer session" then using sticky sessions is not an option unfortunately. Chris McCormack -Original Message- From: Paul McCulloch [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 14:54 To: 'Struts Users Mailing List' Subject: RE: some best practices questions The solution to this problem is to use a load balancer which knows about sessions. mod_jk2 for Apache does this very well. With sticky sessions enabled the first request in a session goes, as you say, to a low load box. All subsequent requests in that session will be sent to the same box. You don't have to make *any* changes to your application to support this. The only downside (vs a 'real' cluster) is that in the event of a box dying users will fail over to another box with nothing in their session. Paul > -Original Message- > From: McCormack, Chris [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 14:09 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: RE: some best practices questions > > > >3) Users session is on that machine. The url for that > machine is machine123.msn.com. > > You missed a few steps which outlines the problem with > clustered servers not being able to use session scope for a user : > > -a user types in their login details on www.msn.com and hits "GO". > > -the request hits www.msn.com and the load balancer assigns > the request to a low load box and rewrites > the url and forwards the request on ie serv1.msn.com > > -the request lands at serv1.msn.com and the application on > serv1.msn.com services the request and pops a few things in > session scope for use later now it knows who the user is > because they just logged on, it then sends back a valid > response with the users page. > > -the user gets his response and decides to click their > personalised news link www.msn.com/news > > - we are then submitting a new request to www.msn.com. The > load balancer(front processor) may decide that serv1.msn.com > is under load or is not available for this request and sends > to serv24.msn.com. > > - The users session is not on this machine so the application > cannot obtain the info it needs about the user to proceed > with the request. The application has to : > a, get the user to relogin > b, fail horribly or with a nice smiley message :P > > The ways around this have been to : > > c, use black magic to retrieve the users session > > by black magic I mean cookies with a state id in/a sessionid > in the httpheader/session id in a url parameter/hidden form > field on a page that matches to a database/file/static > storage record containing the users session i
RE: some best practices questions
>users will fail over to another box with nothing in their session. In some applications this is an acceptable risk if you have high uptime servers and very few code releases. If you however want a solid insurable "customer session" then using sticky sessions is not an option unfortunately. Chris McCormack -Original Message- From: Paul McCulloch [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 14:54 To: 'Struts Users Mailing List' Subject: RE: some best practices questions The solution to this problem is to use a load balancer which knows about sessions. mod_jk2 for Apache does this very well. With sticky sessions enabled the first request in a session goes, as you say, to a low load box. All subsequent requests in that session will be sent to the same box. You don't have to make *any* changes to your application to support this. The only downside (vs a 'real' cluster) is that in the event of a box dying users will fail over to another box with nothing in their session. Paul > -Original Message- > From: McCormack, Chris [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 14:09 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: RE: some best practices questions > > > >3) Users session is on that machine. The url for that > machine is machine123.msn.com. > > You missed a few steps which outlines the problem with > clustered servers not being able to use session scope for a user : > > -a user types in their login details on www.msn.com and hits "GO". > > -the request hits www.msn.com and the load balancer assigns > the request to a low load box and rewrites > the url and forwards the request on ie serv1.msn.com > > -the request lands at serv1.msn.com and the application on > serv1.msn.com services the request and pops a few things in > session scope for use later now it knows who the user is > because they just logged on, it then sends back a valid > response with the users page. > > -the user gets his response and decides to click their > personalised news link www.msn.com/news > > - we are then submitting a new request to www.msn.com. The > load balancer(front processor) may decide that serv1.msn.com > is under load or is not available for this request and sends > to serv24.msn.com. > > - The users session is not on this machine so the application > cannot obtain the info it needs about the user to proceed > with the request. The application has to : > a, get the user to relogin > b, fail horribly or with a nice smiley message :P > > The ways around this have been to : > > c, use black magic to retrieve the users session > > by black magic I mean cookies with a state id in/a sessionid > in the httpheader/session id in a url parameter/hidden form > field on a page that matches to a database/file/static > storage record containing the users session information. > > The point is if you use load balanced application server > clustering its not straight forward to implement session > handling and everyone does it differently subject to their > applications needs. > > Chris McCormack > > -Original Message- > From: Bryan Hunt [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 13:00 > To: Struts Users Mailing List > Subject: Re: some best practices questions > > > The main arguments that people have against session storage > is the following > > a) Excessive memory consumption limits scallability. > True, just don't go crazy storing whole db's and stuff in there. > > b) Sessions can not be shared by webservers in clustered environment. > > Clustered webservers with shared sessions are such a myth/stupid idea. > Do it like hotmail. > > 1) Request comes in to one of the front processor > machines selected by > DNS server with multiple resolves for the same address. > > 2) Choose a machine that that has resources to spare. > > 3) Users session is on that machine. The url for that machine is > machine123.msn.com. > > 4) User logs off, the next time they come back their session is on > some other machine. > > I fail to see what the point of sharing sessions between machines is ? > Even if the machine crashes, they just enter in the initial > address (ie > hotmail.com ) and get sent to a working machine. > > So my point is ... what's so bad about sessions ? > > Also if session ties you to a machine then file storage is > twice as bad. > > --b > > > > > > *** > This e-mail and its attachments are confidential > and are intended for the above named recipient > only. If thi
RE: some best practices questions
The solution to this problem is to use a load balancer which knows about sessions. mod_jk2 for Apache does this very well. With sticky sessions enabled the first request in a session goes, as you say, to a low load box. All subsequent requests in that session will be sent to the same box. You don't have to make *any* changes to your application to support this. The only downside (vs a 'real' cluster) is that in the event of a box dying users will fail over to another box with nothing in their session. Paul > -Original Message- > From: McCormack, Chris [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 14:09 > To: Struts Users Mailing List; [EMAIL PROTECTED] > Subject: RE: some best practices questions > > > >3) Users session is on that machine. The url for that > machine is machine123.msn.com. > > You missed a few steps which outlines the problem with > clustered servers not being able to use session scope for a user : > > -a user types in their login details on www.msn.com and hits "GO". > > -the request hits www.msn.com and the load balancer assigns > the request to a low load box and rewrites > the url and forwards the request on ie serv1.msn.com > > -the request lands at serv1.msn.com and the application on > serv1.msn.com services the request and pops a few things in > session scope for use later now it knows who the user is > because they just logged on, it then sends back a valid > response with the users page. > > -the user gets his response and decides to click their > personalised news link www.msn.com/news > > - we are then submitting a new request to www.msn.com. The > load balancer(front processor) may decide that serv1.msn.com > is under load or is not available for this request and sends > to serv24.msn.com. > > - The users session is not on this machine so the application > cannot obtain the info it needs about the user to proceed > with the request. The application has to : > a, get the user to relogin > b, fail horribly or with a nice smiley message :P > > The ways around this have been to : > > c, use black magic to retrieve the users session > > by black magic I mean cookies with a state id in/a sessionid > in the httpheader/session id in a url parameter/hidden form > field on a page that matches to a database/file/static > storage record containing the users session information. > > The point is if you use load balanced application server > clustering its not straight forward to implement session > handling and everyone does it differently subject to their > applications needs. > > Chris McCormack > > -Original Message- > From: Bryan Hunt [mailto:[EMAIL PROTECTED] > Sent: 08 July 2004 13:00 > To: Struts Users Mailing List > Subject: Re: some best practices questions > > > The main arguments that people have against session storage > is the following > > a) Excessive memory consumption limits scallability. > True, just don't go crazy storing whole db's and stuff in there. > > b) Sessions can not be shared by webservers in clustered environment. > > Clustered webservers with shared sessions are such a myth/stupid idea. > Do it like hotmail. > > 1) Request comes in to one of the front processor > machines selected by > DNS server with multiple resolves for the same address. > > 2) Choose a machine that that has resources to spare. > > 3) Users session is on that machine. The url for that machine is > machine123.msn.com. > > 4) User logs off, the next time they come back their session is on > some other machine. > > I fail to see what the point of sharing sessions between machines is ? > Even if the machine crashes, they just enter in the initial > address (ie > hotmail.com ) and get sent to a working machine. > > So my point is ... what's so bad about sessions ? > > Also if session ties you to a machine then file storage is > twice as bad. > > --b > > > > > > *** > This e-mail and its attachments are confidential > and are intended for the above named recipient > only. If this has come to you in error, please > notify the sender immediately and delete this > e-mail from your system. > You must take no action based on this, nor must > you copy or disclose it or any part of its contents > to any person or organisation. > Statements and opinions contained in this email may > not necessarily represent those of Littlewoods. > Please note that e-mail communications may be monitored. > The r
Re: some best practices questions
Essentially, this is what ASP.NET does by default. The original values for the
controls that you want to persist are encoded and serialized and written to the form
as a single hidden variable. Then on the server side, it unmarshalls the hidden
variable and restores the controls to their original state. Any request parameters are
then applied so update the controls to their new values.
IMHO, it would be very useful to have a tag that serialized the ActionForm so that you
would have a copy of its prior state. Ideally, the request processor would first
repopulate the ActionForm from the serialized copy, and then look to the request
parameters (a la .NET).
Or course, there is no free lunch. You save on the server, but you pay on the client,
since all this serialized data has to be rendered by your browser. But, it would avoid
over-using session scope.
-Ted.
On Wed, 07 Jul 2004 22:46:04 -0400, Christina Siena wrote:
> 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
>>
>>
>> Christin
RE: some best practices questions
>3) Users session is on that machine. The url for that machine is machine123.msn.com. You missed a few steps which outlines the problem with clustered servers not being able to use session scope for a user : -a user types in their login details on www.msn.com and hits "GO". -the request hits www.msn.com and the load balancer assigns the request to a low load box and rewrites the url and forwards the request on ie serv1.msn.com -the request lands at serv1.msn.com and the application on serv1.msn.com services the request and pops a few things in session scope for use later now it knows who the user is because they just logged on, it then sends back a valid response with the users page. -the user gets his response and decides to click their personalised news link www.msn.com/news - we are then submitting a new request to www.msn.com. The load balancer(front processor) may decide that serv1.msn.com is under load or is not available for this request and sends to serv24.msn.com. - The users session is not on this machine so the application cannot obtain the info it needs about the user to proceed with the request. The application has to : a, get the user to relogin b, fail horribly or with a nice smiley message :P The ways around this have been to : c, use black magic to retrieve the users session by black magic I mean cookies with a state id in/a sessionid in the httpheader/session id in a url parameter/hidden form field on a page that matches to a database/file/static storage record containing the users session information. The point is if you use load balanced application server clustering its not straight forward to implement session handling and everyone does it differently subject to their applications needs. Chris McCormack -Original Message- From: Bryan Hunt [mailto:[EMAIL PROTECTED] Sent: 08 July 2004 13:00 To: Struts Users Mailing List Subject: Re: some best practices questions The main arguments that people have against session storage is the following a) Excessive memory consumption limits scallability. True, just don't go crazy storing whole db's and stuff in there. b) Sessions can not be shared by webservers in clustered environment. Clustered webservers with shared sessions are such a myth/stupid idea. Do it like hotmail. 1) Request comes in to one of the front processor machines selected by DNS server with multiple resolves for the same address. 2) Choose a machine that that has resources to spare. 3) Users session is on that machine. The url for that machine is machine123.msn.com. 4) User logs off, the next time they come back their session is on some other machine. I fail to see what the point of sharing sessions between machines is ? Even if the machine crashes, they just enter in the initial address (ie hotmail.com ) and get sent to a working machine. So my point is ... what's so bad about sessions ? Also if session ties you to a machine then file storage is twice as bad. --b *** This e-mail and its attachments are confidential and are intended for the above named recipient only. If this has come to you in error, please notify the sender immediately and delete this e-mail from your system. You must take no action based on this, nor must you copy or disclose it or any part of its contents to any person or organisation. Statements and opinions contained in this email may not necessarily represent those of Littlewoods. Please note that e-mail communications may be monitored. The registered office of Littlewoods Limited and its subsidiaries is 100 Old Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods Limited is 262152. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some best practices questions
The main arguments that people have against session storage is the following
a) Excessive memory consumption limits scallability.
True, just don't go crazy storing whole db's and stuff in there.
b) Sessions can not be shared by webservers in clustered environment.
Clustered webservers with shared sessions are such a myth/stupid idea.
Do it like hotmail.
1) Request comes in to one of the front processor machines selected by
DNS server with multiple resolves for the same address.
2) Choose a machine that that has resources to spare.
3) Users session is on that machine. The url for that machine is
machine123.msn.com.
4) User logs off, the next time they come back their session is on
some other machine.
I fail to see what the point of sharing sessions between machines is ?
Even if the machine crashes, they just enter in the initial address (ie
hotmail.com ) and get sent to a working machine.
So my point is ... what's so bad about sessions ?
Also if session ties you to a machine then file storage is twice as bad.
--b
[EMAIL PROTECTED] wrote:
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
>
RE: some best practices questions
At 12:36 AM 7/8/2004, you wrote: 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. my 2c The thing is, though, Andrew, these are recurrent issues and seem to require a generic solution. Having a small manager in application scope which can create and monitor a scope which is not application, not session, and not request, is worth the while for these recurrent problems, I think. The persistence of such a scope can be made a function of the data rather than the interest of the clients. That is worth having to use on a general basis, I think, and can be done with a very small performance hit. In fact, my guess is that it would be a performance plus. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
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.
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.
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
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
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
Re: some best practices questions
Your idea about creating a new scope sounds like an idea that might help. Can you tell me more about it? - 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 m
Re: some best practices questions
I myself get caching with hibernate which I am using for persistance
but I wanted the more fine grained control like this so that I could page
back and forth using displaytag.org.
here is my jsp code for paging, hope this shows why I am doing it. I guess
my code is more for implimenting a client view than for heavy duty caching.
snip=
<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
<%@ taglib uri="/tags/c" prefix="c" %>
<%@ taglib uri="/tags/displaytag-el-12" prefix="display" %>
=snip
Cause everything is cached it is a snip to move back and forth through
the records.
--b
On Wed, 07 Jul 2004 08:41:39 -0700, Michael McGrady
<[EMAIL PROTECTED]> wrote:
> I, for one and one only, think that this sort of thing is directly
> addressing the most common recurrent question on this list. So, if
> anything, this de-spams the list. Thanks for the suggestion.
>
> At 04:57 AM 7/7/2004, you wrote:
> >Sorry if this is considered spamming the list
> >
> >Speaking of storing stuff in session scope. I've developed what I think is
> >a handy class which I think it useful for
> >when I want to store something like a search in a session variable.
> >
> >For instance if I want to page through it ( using displaytags.org (10 out
> >of 10)) or simply if I don't want to fetch
> >from the database time and time again.
> >By default the data expires on an hourly basis. And if a different
> >combination of parameters is sent it expires
> >the cached stuff.
> >
> >Here is the class
> >
> >snip=
> >package ie.jestate.struts.client;
> >
> >import java.util.Date;
> >
> >/**
> >* @author Bryan Hunt
> >*/
> >//TODO:Perhaps I should be generating a MD5 or something but I can't see a
> >good reason to use any more CPU
> >
> >public class HashGenerator {
> >
> >private StringBuffer buffer;
> >
> >
> >/**
> > *
> > */
> >public HashGenerator() {
> >super();
> >buffer = new StringBuffer(50);
> >// TODO Auto-generated constructor stub
> >}
> >
> >/**
> > * @param urbanAreas
> > */
> >public void add(Integer[] array,String fieldname) {
> >for (int i = 0; i < array.length; i++) {
> >Integer integer = array[i];
> >buffer.append(integer);
> >}
> >buffer.append(fieldname);
> >buffer.append("-");
> >}
> >
> >/**
> > * @param priceRangeStart
> > */
> >public void add(Integer integer,String fieldname) {
> >// TODO Auto-generated method stub
> >buffer.append(integer);
> >buffer.append(fieldname);
> >buffer.append("-");
> >}
> >
> >/**
> > * @return
> > */
> >public String getHash() {
> >
> >//I append the hour onto the end of the string so that a hash will
> >//only be good for a max of one hour.
> >Date date = new Date();
> >
> >return buffer.toString()+ "-" + new Integer(date.getHours());
> >}
> >
> >}
> >
> >=snip
> >
> >And here is example usage.
> >snip=
> >/*
> >* Created on 24-Jun-2004
> >*/
> >package ie.jestate.struts.client;
> >
> >import ie.jestate.struts.BaseAction;
> >
> >import java.util.Set;
> >
> >import javax.servlet.http.HttpServletRequest;
> >import javax.servlet.http.HttpServletResponse;
> >import javax.servlet.http.HttpSession;
> >
> >import org.apache.struts.action.ActionForm;
> >import org.apache.struts.action.ActionForward;
> >import org.apache.struts.action.ActionMapping;
> >import org.apache.struts.action.DynaActionForm;
> >
> >/**
> >* @author Bryan Hunt
> > *
> >*/
> >public class ForSaleSearchAction extends BaseAction {
> >
> >/* (non-Javadoc)
> > * @see
> > org.apache.struts.action.Action#execute(org.apache.struts.action.ActionMapping,
> > org.apache.struts.action.ActionForm,
> > javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
> > */
> >public ActionForward execute(
> >ActionMapping actionMapping,
> >ActionForm actionForm,
> >HttpServletRequest request,
> >HttpServletResponse response)
> >throws Exception {
> >
> >//TODO: Database based initialization of the countries collection
> >DynaActionForm dynaform = (DynaActionForm) actionForm;
> >HttpSession session = request.getSession();
> >String forSalePropertiesSearchCheckSum = (String)
> > session.getAttribute(Constants.FOR_SALE_CHECK_SUM);
> >String newForSalePropertiesSearchCheckSum = null;
> >
> >Integer[] urbanAreas = (Integer[]) dynaform.get("urbanAreas");
> >Integer priceRangeStart = (Integer) dynaform.get("priceRangeStart");
> >Integer priceRangeEnd = (Integer) dynaform.get("priceRangeEnd");
> >Integer[] propertyTypes = (Integer[]) dynaform.get("propertyTypes");
> >
> >HashGenerator hashGenerator =
Re: some best practices questions
I, for one and one only, think that this sort of thing is directly
addressing the most common recurrent question on this list. So, if
anything, this de-spams the list. Thanks for the suggestion.
At 04:57 AM 7/7/2004, you wrote:
Sorry if this is considered spamming the list
Speaking of storing stuff in session scope. I've developed what I think is
a handy class which I think it useful for
when I want to store something like a search in a session variable.
For instance if I want to page through it ( using displaytags.org (10 out
of 10)) or simply if I don't want to fetch
from the database time and time again.
By default the data expires on an hourly basis. And if a different
combination of parameters is sent it expires
the cached stuff.
Here is the class
snip=
package ie.jestate.struts.client;
import java.util.Date;
/**
* @author Bryan Hunt
*/
//TODO:Perhaps I should be generating a MD5 or something but I can't see a
good reason to use any more CPU
public class HashGenerator {
private StringBuffer buffer;
/**
*
*/
public HashGenerator() {
super();
buffer = new StringBuffer(50);
// TODO Auto-generated constructor stub
}
/**
* @param urbanAreas
*/
public void add(Integer[] array,String fieldname) {
for (int i = 0; i < array.length; i++) {
Integer integer = array[i];
buffer.append(integer);
}
buffer.append(fieldname);
buffer.append("-");
}
/**
* @param priceRangeStart
*/
public void add(Integer integer,String fieldname) {
// TODO Auto-generated method stub
buffer.append(integer);
buffer.append(fieldname);
buffer.append("-");
}
/**
* @return
*/
public String getHash() {
//I append the hour onto the end of the string so that a hash will
//only be good for a max of one hour.
Date date = new Date();
return buffer.toString()+ "-" + new Integer(date.getHours());
}
}
=snip
And here is example usage.
snip=
/*
* Created on 24-Jun-2004
*/
package ie.jestate.struts.client;
import ie.jestate.struts.BaseAction;
import java.util.Set;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.DynaActionForm;
/**
* @author Bryan Hunt
*
*/
public class ForSaleSearchAction extends BaseAction {
/* (non-Javadoc)
* @see
org.apache.struts.action.Action#execute(org.apache.struts.action.ActionMapping,
org.apache.struts.action.ActionForm,
javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
*/
public ActionForward execute(
ActionMapping actionMapping,
ActionForm actionForm,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
//TODO: Database based initialization of the countries collection
DynaActionForm dynaform = (DynaActionForm) actionForm;
HttpSession session = request.getSession();
String forSalePropertiesSearchCheckSum = (String)
session.getAttribute(Constants.FOR_SALE_CHECK_SUM);
String newForSalePropertiesSearchCheckSum = null;
Integer[] urbanAreas = (Integer[]) dynaform.get("urbanAreas");
Integer priceRangeStart = (Integer) dynaform.get("priceRangeStart");
Integer priceRangeEnd = (Integer) dynaform.get("priceRangeEnd");
Integer[] propertyTypes = (Integer[]) dynaform.get("propertyTypes");
HashGenerator hashGenerator = new HashGenerator();
hashGenerator.add(urbanAreas,"urbanAreas");
hashGenerator.add(priceRangeStart,"priceRangeStart");
hashGenerator.add(priceRangeEnd,"priceRangeEnd");
hashGenerator.add(propertyTypes,"propertyTypes");
newForSalePropertiesSearchCheckSum =
hashGenerator.getHash();
if(forSalePropertiesSearchCheckSum != null &&
forSalePropertiesSearchCheckSum.equals(newForSalePropertiesSearchCheckSum)) {
System.out.println("Checksums match");
}
if (forSalePropertiesSearchCheckSum == null
||
!forSalePropertiesSearchCheckSum.equals(newForSalePropertiesSearchCheckSum)){
Set forSaleProperties =
findForSaleProperties(
urbanAreas,
priceRangeStart,
priceRangeEnd,
propertyTypes);
session.setAttribute(Constants.FOR_SALE_PROPERTIES_SEARCH_RESULT,
forSaleProperties);
session.setAttribute(
Constants.FOR_SALE_CHECK_SUM,
newForSalePropertiesSearchCheckSum);
//TODO:Add logging functionality
System.out.println("Returning fresh search results");
} else
/*
Re: some best practices questions
On Wed, 07 Jul 2004 13:57:23 +0200, Bryan Hunt <[EMAIL PROTECTED]> wrote: For instance if I want to page through it ( using displaytags.org (10 out of 10)) or simply if I don't want to fetch from the database time and time again. By default the data expires on an hourly basis. And if a different combination of parameters is sent it expires the cached stuff. Nice code, but if you use iBATIS http://www.ibatis.com for your persistence layer you get all of that functionality out of the box. Takes care of all the caching for you. It'll even always flush the cache whenever an update or insert is peformed. So basically you make the same simple DAO call... ie. myDao.getMyList().. and you don't have to worry about it whether you need a fresh query or not. Unfortunately as cool as caching is, in many(most?) situations the database is not just modified by your application, so you can't rely on the cache being flushed at appropriate times. For example say the inventory to display is updated in the database by some other process outside of your web application. When displaying the inventory you always want to make sure you have the most recent inventory so you can't rely on caching. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some best practices questions
Sorry if this is considered spamming the list
Speaking of storing stuff in session scope. I've developed what I think
is a handy class which I think it useful for
when I want to store something like a search in a session variable.
For instance if I want to page through it ( using displaytags.org (10
out of 10)) or simply if I don't want to fetch
from the database time and time again.
By default the data expires on an hourly basis. And if a different
combination of parameters is sent it expires
the cached stuff.
Here is the class
snip=
package ie.jestate.struts.client;
import java.util.Date;
/**
* @author Bryan Hunt
*/
//TODO:Perhaps I should be generating a MD5 or something but I can't see
a good reason to use any more CPU
public class HashGenerator {
private StringBuffer buffer;
/**
*
*/
public HashGenerator() {
super();
buffer = new StringBuffer(50);
// TODO Auto-generated constructor stub
}
/**
* @param urbanAreas
*/
public void add(Integer[] array,String fieldname) {
for (int i = 0; i < array.length; i++) {
Integer integer = array[i];
buffer.append(integer);
}
buffer.append(fieldname);
buffer.append("-");
}
/**
* @param priceRangeStart
*/
public void add(Integer integer,String fieldname) {
// TODO Auto-generated method stub
buffer.append(integer);
buffer.append(fieldname);
buffer.append("-");
}
/**
* @return
*/
public String getHash() {
//I append the hour onto the end of the string so that a hash will
//only be good for a max of one hour.
Date date = new Date();
return buffer.toString()+ "-" + new Integer(date.getHours());
}
}
=snip
And here is example usage.
snip=
/*
* Created on 24-Jun-2004
*/
package ie.jestate.struts.client;
import ie.jestate.struts.BaseAction;
import java.util.Set;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.apache.struts.action.DynaActionForm;
/**
* @author Bryan Hunt
*
*/
public class ForSaleSearchAction extends BaseAction {
/* (non-Javadoc)
* @see
org.apache.struts.action.Action#execute(org.apache.struts.action.ActionMapping,
org.apache.struts.action.ActionForm,
javax.servlet.http.HttpServletRequest,
javax.servlet.http.HttpServletResponse)
*/
public ActionForward execute(
ActionMapping actionMapping,
ActionForm actionForm,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
//TODO: Database based initialization of the countries collection
DynaActionForm dynaform = (DynaActionForm) actionForm;
HttpSession session = request.getSession();
String forSalePropertiesSearchCheckSum = (String)
session.getAttribute(Constants.FOR_SALE_CHECK_SUM);
String newForSalePropertiesSearchCheckSum = null;
Integer[] urbanAreas = (Integer[]) dynaform.get("urbanAreas");
Integer priceRangeStart = (Integer) dynaform.get("priceRangeStart");
Integer priceRangeEnd = (Integer) dynaform.get("priceRangeEnd");
Integer[] propertyTypes = (Integer[]) dynaform.get("propertyTypes");
HashGenerator hashGenerator = new HashGenerator();
hashGenerator.add(urbanAreas,"urbanAreas");
hashGenerator.add(priceRangeStart,"priceRangeStart");
hashGenerator.add(priceRangeEnd,"priceRangeEnd");
hashGenerator.add(propertyTypes,"propertyTypes");
newForSalePropertiesSearchCheckSum =
hashGenerator.getHash();
if(forSalePropertiesSearchCheckSum != null &&
forSalePropertiesSearchCheckSum.equals(newForSalePropertiesSearchCheckSum))
{
System.out.println("Checksums match");
}
if (forSalePropertiesSearchCheckSum == null
||
!forSalePropertiesSearchCheckSum.equals(newForSalePropertiesSearchCheckSum)){
Set forSaleProperties =
findForSaleProperties(
urbanAreas,
priceRangeStart,
priceRangeEnd,
propertyTypes);
session.setAttribute(Constants.FOR_SALE_PROPERTIES_SEARCH_RESULT,
forSaleProperties);
session.setAttribute(
Constants.FOR_SALE_CHECK_SUM,
newForSalePropertiesSearchCheckSum);
//TODO:Add logging functionality
System.out.println("Returning fresh search results");
} else
/*
if (
session.getAttribute("forSalePropertiesSearchCheckSum").equals(
forSalePropertiesSearchCheckSum))
Re: some best practices questions
Thanks for the heads up, Rick. I think this whole area just needs a concerted and orchestrated look. The standard approaches just are not working for people. This is really so recurrent is more than recurrent. At 09:59 PM 7/6/2004, you wrote: On Tue, 06 Jul 2004 20:58:16 -0700, Michael McGrady <[EMAIL PROTECTED]> wrote: I wouldn't mind an ongoing discussion group on this alone somehow, if there were a way to do that. I might create a forum for that. I created a model-struts group on yahoo groups for discussing more of the model layer components as they relate to struts. However, this list is rarely used. (Robert Taylor and myself are the only ones who answer the occoassional questions there:) I suggest just bringing up any of the discussion here on this list. Makes it nice for when you want to get info back from the archives. Plus nice to hear about practical solutions people have to solving common issues. -- 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]
Re: some best practices questions
On Tue, 06 Jul 2004 20:58:16 -0700, Michael McGrady <[EMAIL PROTECTED]> wrote: I wouldn't mind an ongoing discussion group on this alone somehow, if there were a way to do that. I might create a forum for that. I created a model-struts group on yahoo groups for discussing more of the model layer components as they relate to struts. However, this list is rarely used. (Robert Taylor and myself are the only ones who answer the occoassional questions there:) I suggest just bringing up any of the discussion here on this list. Makes it nice for when you want to get info back from the archives. Plus nice to hear about practical solutions people have to solving common issues. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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'
Re: some best practices questions
I think the obvious is important with this recurrent problem. The obvious is that you want to persist data for a period that is not coincident with the normal devices for doing that. i.e. request, session and context scopes. The difficulty is matching up with storage method on the server with the "life-term" of the client. There are any number of solutions to this problem with varying pluses and minuses, and I think you really have to solve what you need for your problem. I have no doubt that there are recurrent problems and that some general solutions to those particular recurrent problems would be useful. I have been mulling this around in my head for a while trying to get some sense about this. I wouldn't mind an ongoing discussion group on this alone somehow, if there were a way to do that. I might create a forum for that. At 07:43 PM 7/6/2004, you 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? Any ideas would be appreciated. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: some best practices questions
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
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]
