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) <ika...@google.com> 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 <jefftschwa...@gmail.com>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 <onepagewo...@gmail.com
>> > wrote:
>>
>>> 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%2bunsubscr...@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%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<google-appengine%2bunsubscr...@googlegroups.com>
>> .
>> 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 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.
