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.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
