I'm not sure what you mean by 'globals'. Static fields are not global - they must be referenced using a class name.
On Fri, Jul 30, 2010 at 1:23 PM, Ikai L (Google) <[email protected]> wrote: > I avoided this thread because I wanted to see some code first. It sounded > like the original poster wanted to use globals in a non-thread safe way. > > Statics are not a bad thing, but using globals to pass state around that is > only useful in local scope is very, very bad. > > On Fri, Jul 30, 2010 at 7:11 AM, Jeff Schwartz <[email protected]>wrote: > >> Hi Stephen, >> >> I hope I wasn't perceived as someone trying to be right. I was only trying >> to prevent other readers from being misinformed. >> >> Modern programming languages offer a lot of useful 'tools' that empower >> the kinds of programming constructs that at one time were only dreamed of. >> It would be wasteful if one didn't take advantage of them. >> >> Jeff >> >> >> On Thu, Jul 29, 2010 at 10:55 PM, Stephen Johnson <[email protected] >> > wrote: >> >>> 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%[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%[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%[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%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > > > -- > Ikai Lan > Developer Programs Engineer, Google App Engine > Blog: http://googleappengine.blogspot.com > Twitter: http://twitter.com/app_engine > Reddit: http://www.reddit.com/r/appengine > > -- > 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%[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.
