[google-appengine] Re: Is it really bad to define global variables?
On Jul 30, 8:47 pm, Ikai L (Google) ika...@google.com wrote: 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. Just for the sake of completeness, this case is usually implemented using a static ThreadLocal instance. But I agree that it should be avoided. -- 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.
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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.comwrote:
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
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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.comwrote:
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.comwrote:
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
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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.comwrote:
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.comwrote:
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.comwrote:
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
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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.comwrote:
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.comwrote:
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.comwrote:
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
[google-appengine] Re: Is it really bad to define global variables?
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-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.
Re: [google-appengine] Re: Is it really bad to define global variables?
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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.comgoogle-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.
[google-appengine] Re: Is it really bad to define global variables?
Hi On Jul 29, 8:40 pm, 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? Wouldn't have a clue. I don't use java on appengine. You didn't mention in your original post you where specifically talking about java. In python class/module cached definitions last for as long as the app instance is running. T 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-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.comgoogle-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.
Re: [google-appengine] Re: Is it really bad to define global variables?
I wasn't the original poster but I was curious about your caution regarding class static fields. Which Python framework are you using if you don't mind me asking? Jeff On Thu, Jul 29, 2010 at 10:49 AM, Tim Hoffman zutes...@gmail.com wrote: Hi On Jul 29, 8:40 pm, 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? Wouldn't have a clue. I don't use java on appengine. You didn't mention in your original post you where specifically talking about java. In python class/module cached definitions last for as long as the app instance is running. T 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.comgoogle-appengine%2bunsubscr...@googlegroups.comgoogle-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.comgoogle-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.
[google-appengine] Re: Is it really bad to define global variables?
Hi On Jul 29, 11:32 pm, Jeff Schwartz jefftschwa...@gmail.com wrote: I wasn't the original poster but I was curious about your caution regarding class static fields. Sorry missed that. Having not done any development with java on appengine all my development (and hence statements about module level caches) Which Python framework are you using if you don't mind me asking? www.polytechnic.wa.edu.au is based on repoze.bfg (http:// bfg.repoze.org/) The current project I am working on is based on bobo, zope.component, formish and repoze.what. (and using a simple bfg based cms for help content). Rgds T Jeff On Thu, Jul 29, 2010 at 10:49 AM, Tim Hoffman zutes...@gmail.com wrote: Hi On Jul 29, 8:40 pm, 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? Wouldn't have a clue. I don't use java on appengine. You didn't mention in your original post you where specifically talking about java. In python class/module cached definitions last for as long as the app instance is running. T 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.comgoogle-appengine%2Bunsubscrib e...@googlegroups.comgoogle-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.comgoogle-appengine%2Bunsubscrib e...@googlegroups.com . For more options, visit this group at
[google-appengine] Re: Is it really bad to define global variables?
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
Re: [google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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
[google-appengine] Re: Is it really bad to define global variables?
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.comwrote:
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
