Yes Jeff, you are correct, constant values are safe to use. On Jul 29, 7:23 pm, Jeff Schwartz <[email protected]> wrote: > Stephen > > With all due respect, you are stating the obvious and the use case you > present is like a text book example of last in first out/race ahead > condition. Perhaps if the coder had declared the static variable final and > initialized it in a static constructor it would have prevented multiple > assignments - assuming a single class loader of course and a single class > cache. > > Not that your point isn't valid. One does have to take care when using any > language feature, Java or any language for that matter. That is obvious I > hope. > > In any case I wouldn't advise anyone from avoiding using static class fields > if it fits their use case. With care they can and are used without any > problems. > > Jeff > > On Thu, Jul 29, 2010 at 9:02 PM, Stephen Johnson > <[email protected]>wrote: > > > > > > > Hi Jeff (and possible Bill if you're using Java and not Python (not > > sure from the question since I don't know Python)) > > (Assuming Java) Using static variables could cause all kinds of > > trouble if proper care is not taken to limit their accessibility since > > they are shared and all requests that are being handled by that > > particular JVM instance be accessing the same data. That data would be > > accessible for simultaneous requests and would also survive after the > > requests have finished processing and would be available to the next > > request(s). This data would exist until GAE shutdown that particular > > app instance on that JVM (or restarted due to a deployment, etc.) > > Other JVM instances of the app would have different values. > > > So, for example, if we have: > > > public class Beta { > > public int x; > > } > > > public class Alpha { > > public static Beta beta; > > } > > > So if Servlet #1 receives a request and does: > > > Beta b = new Beta(); > > b.x = 5; > > Alpha.beta.x = b; > > > And then Servlet #2 receives a request and does: > > Beta b = new Beta(); > > b.x = 17; > > Alpha.beta.x = b; > > > And then Servlet #1 continues processing: > > b.x = b.x + 5; > > *** Oops! b.x is now 17, not 5 *** > > > Also, this Beta object will exist even after the requests have all > > finished since the static instance will stick around. Note, that this > > occurs even though these objects are not Serializable. > > > So, Jeff in response to: > > > If storing values in class static fields were problematic I'd guess that > > > this would break quite a number of web apps. What do you think? > > Well, static variables are by their very nature are supposed to be > > shared and are not a problem if used correctly and for that purpose, > > but in Bill's case he would be attempting to use a shared variable as > > if it were a private variable accessible only to a particular request > > and so would be used incorrectly and could cause problems for his web > > app. > > > Okay, so static variables may not be ok. What about storing the data > > in an instance variable of the Servlet?? Well, that wouldn't work > > either since the servlet container only creates one instance of each > > servlet class, thus the instance variables of the servlet classes act > > almost like static variables, that is, they are shared amongst all > > requests to that servlet and would survive even after the requests > > have finished processing since the servlet container will keep the > > servlet instances alive until the servlet container shuts down. > > > So, if Bill is using Java, then what should he do. Well, > > 1.) I'm not sure why you have to re-sync the object A that is passed > > in the constructors of the other objects with the handler's object A. > > In Java, these would be the same object unless you are making some > > sort of clone (or copy). So, I think your approach works. At least for > > Java. Unless you've left some detail out. > > 2.) So what you can do is you can use the ThreadLocal class to store > > object A. The ThreadLocal class acts like a Map but the values are > > specific to each thread and other threads don't see each other's > > values. So, at the beginning of the request you can store object A > > into the ThreadLocal object and then objects B, C, D, etc. can access > > that object by key. One caveat is that these values would be available > > to the next request that is handled by that thread so you'd need to > > make sure you clear these values at either the ending or beginning of > > each request. > > > Stephen > > > On Jul 29, 5:40 am, Jeff Schwartz <[email protected]> wrote: > > > Hi Tim. > > > > Help me out here 'cause I don't understand what problem you see with > > storing > > > a value in a static field? > > > > As far as I know (and I am limiting my discussion here to Java and > > servlets) > > > objects are not persisted across http requests unless they are > > serializable > > > and stored in session or in memcache and that takes programming effort > > > meaning you have to deliberately program the behavior. > > > > Yes there are statefull web frameworks such as Wicket and JSF for > > instance > > > that will persist objects accross requests without programming effort but > > > even these are limited to model and view class instances for the most > > part. > > > > As for classes (not instances) persisting across requests (and > > eliminating > > > those classes that are servlet and other server pluming classes) what > > > classes are persisted across requests? > > > > If storing values in class static fields were problematic I'd guess that > > > this would break quite a number of web apps. What do you think? > > > > Jeff > > > > On Thu, Jul 29, 2010 at 7:31 AM, Tim Hoffman <[email protected]> wrote: > > > > The biggest problem I see with storing the value at a class/module > > > > level > > > > is you really need to make sure you clean up after yourself, otherwise > > > > the > > > > value may still be set when the next request is processed and that > > > > value may not be > > > > appropriate. > > > > > I would personally always grab/cache values in request object, > > > > memcache, and or session > > > > as appropriate. > > > > > That way there is no danger of exposing data to other requests. > > > > > But hey, if you want to use module level caches go for it. > > > > > I have been running appengine projects ever since it was released and > > > > started out with some > > > > module level cache, and regretted it ever since. It was has proven to > > > > be difficult ensure the cache > > > > has been cleaned up, where as memcahce you can control out of > > > > process. (You can't shut an instance down > > > > if it has an error and you can't remove a value from a module cache) > > > > > Rgds > > > > > T > > > > > On Jul 29, 4:19 pm, Bill Edwards <[email protected]> wrote: > > > > > Hey guys, > > > > > > Is it horrible to use global variables? I am currently executing a > > > > > query at the beginning of my handler and storing the query result > > > > > within class object A. I subsequently need to access the query > > result > > > > > within multiple different class objects, say B, C, and D. It has > > been > > > > > recommended to me to cache object A in the request object, but i need > > > > > to access the variable from within various class objects, so I'm > > > > > finding that I have to pass the object A in to the constructor for > > > > > every new object i define, and then sync any changed state of object > > A > > > > > with the handler's version of object A when the various class object > > > > > functions are completed. > > > > > > So it really seems like the simplest way to do things is to just > > > > > define a global variable. Is there a better option? Can I think I > > > > > would ideally want to create something liek a session object to store > > > > > the global object. > > > > > > Thanks! > > > > > Bill > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google App Engine" group. > > > > To post to this group, send email to [email protected] > > . > > > > To unsubscribe from this group, send email to > > > > [email protected]<google-appengine%2Bunsubscrib > > > > [email protected]><google-appengine%2Bunsubscrib > > [email protected]> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine?hl=en. > > > > -- > > > -- > > > Jeff > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-appengine%2Bunsubscrib > > [email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. > > -- > -- > Jeff
-- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
