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%2bunsubscr...@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%2bunsubscr...@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.
