Issues associated with enabling multi-threading via <threadsafe>

63 views
Skip to first unread message

Andrew Mackenzie

unread,
Sep 24, 2012, 8:41:25 AM9/24/12
to google-a...@googlegroups.com
I have published an analysis of using multi-threading for GAE/J here http://devcon5.blogspot.com for a project I am working on.

I would very much appreciate any comments, corrections, ommissions or additional questions I should cover. 

Thanks.

Hugo Visser

unread,
Sep 25, 2012, 12:52:04 PM9/25/12
to google-a...@googlegroups.com
Hi Andrew,

To me, the whole point is kinda moot, since threadsafe is a required setting for Java apps (which is a good thing).

Also, the points that you raise in the post are not different from the gotcha's as they are present in a "normal" Java servlet stack. There's not much App Engine specific in there.

The statements like "static initializers are safe" are technically not correct; while it's true for a single instance running multiple threads, your app will still run on multiple instances. So if you are doing something funky in a static initializer (like writing to the datastore) there's still the possibility of race conditions or data corruption.
Same holds true for writing to memcache and the data store that you describe in the post: even if your app is single threaded, a production app will run on multiple instances which could all concurrently write to the same entity or memcache entry.

I hope you find this useful :)

Hugo

Andrew Mackenzie

unread,
Sep 25, 2012, 2:45:17 PM9/25/12
to google-a...@googlegroups.com

Hi Hugo,

Thanks for the comments.

But its not moot. The element in appengine-web.xml is obligatory, but can be set to false. Current production environment respects it. I have done many tests to verify that with overlapped requests and the changes in behaviour when changing that setting.

Point taken about multiple parallel instances and ds/mc. I thought I discussed that but maybe left it out in final version - not "multi-threading within a VM" or affected by setting in question though.....we could call that "instance-safe" :-)

Thanks

Andrew

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/lHqF2_MQTAIJ.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

Hugo Visser

unread,
Sep 25, 2012, 3:34:06 PM9/25/12
to google-a...@googlegroups.com
Yes, you're right, I thought it was required, but supplying the element is now required, thanks for pointing that out.
I don't see why you wouldn't want to use thread safe though, especially for Java apps and libraries that are in other environments also built with thread safety in mind.

Hugo

Andrew Mackenzie

unread,
Sep 25, 2012, 3:40:12 PM9/25/12
to google-a...@googlegroups.com
 Hi Hugo, Oh, we want it all-right, the performance / resource-usage benefits are compelling....but you just need to make sure *your* code (assuming libraries are OK) is ready for it....or you're going to see some pretty difficult to debug bugs.
Reply all
Reply to author
Forward
0 new messages