Yes Jeff, you are correct, constant values are safe to use.
On Jul 29, 7:23 pm, Jeff Schwartz <jefftschwa...@gmail.com> 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
> <onepagewo...@gmail.com>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 <jefftschwa...@gmail.com> 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 <zutes...@gmail.com> 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 <twmaf...@gmail.com> 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 google-appengine@googlegroups.com
> > .
> > > > To unsubscribe from this group, send email to
> > > > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib
> > > > e...@googlegroups.com><google-appengine%2Bunsubscrib
> > e...@googlegroups.com>
> > > > .
> > > > 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 google-appeng...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-appengine+unsubscr...@googlegroups.com<google-appengine%2Bunsubscrib
> > e...@googlegroups.com>
> > .
> > 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 google-appeng...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
