Yup, yup!
I'd bet there's a good design pattern for this.
I'd really like to see more online docs specifically dealing with design
pattern implementations geared towards the different aspects and intricacies
of appengine. The docs could even be tied via links to some of the great
Google IO videos out there on YouTube. Personally, I would love to see this
happen. At a minimum, it would be nice to consolidate the masses into a
centralized index.
Jeff
On Fri, Jul 30, 2010 at 2:47 PM, Ikai L (Google) <ika...@google.com> wrote:
> A static isn't global, but in the OP's use case, it's way out of the scope
> of what he needs to do, which is to pass around objects. Rather than passing
> the object around, it sounded like he just wanted to stash the object into
> global/static scope and pull it out. There are certainly use cases for this,
> but I wanted to discourage it because it sounded like he wanted to do it on
> a per query basis - and there'd be all the problems with global mutable
> state, concurrency, etc. Statics are a great place for configuration (if
> config is loaded via a query that'd be a correct use case) or things which
> don't change frequently. I was just making a point that it seemed like the
> OP was using it for something which *does* change all the time.
>
> On Fri, Jul 30, 2010 at 10:42 AM, Jeff Schwartz
> <jefftschwa...@gmail.com>wrote:
>
>> 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-appengine@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<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.
