0

I want to be clear: I am asking about the case where I am not using any concurrency in my own implementation. I just want to know if the framework within which my backend will be invoked (ie google app engine) itself imposes thread-safety requirements on the code running on it.

Thank you!

P.S. as a related but separate question, is there any guidance on how to do multithreading in our own backend code (which then obviously needs to be appropriately thread-safe). Specifically, can we use java's standard executor services / thread pools, or there is some google-approved API? Thanks.

Creos
  • 2,445
  • 3
  • 27
  • 45

1 Answers1

0

So google app engine or any other platform won't ensure thread safety for you because all the critical sections which your concurrency control techniques are trying to make thread safe are defined by the developer (you) and there is no way for the OS to know when reads and writes should occur. For the JVM, the two main concurrency libraries which are heavily used are the Guava libraries (made by google! ;-) ) and the Akka framework.

Both are great libraries, I've used both and have had a pleasure from their learning curves. I would also recommend looking into the Play Framework, they support the akka framework, and building reactive web apps is their main focus. If you're interested in learning some cool aspects of production frameworks, I would highly recommend learning and implementing Dropwizard (Google app engine doesn't support it, but the take aways you get from it definitely outweigh that con).

Please let me know if you have any questions!

Community
  • 1
  • 1
Devarsh Desai
  • 5,984
  • 3
  • 19
  • 21
  • Ok, so basically there are no native requirements by the frameowrk itself? Any thread-safety demands will be self-imposed based on our own implementation? So if we don't spawn threads directly or indirectly in our backend, there's no need to worry about concurrency? thx – Creos Aug 19 '14 at 02:56
  • 1
    Hey Creos, you're on the right track! Unfortunatly spawning threads isn't the only time you need to worry about concurrency. There's a classic problem called the "bank account problem". Essentially what it boils down to is: controlling the account. Even if you're entire back end is 1 thread per request, let's say you have 500,000 users, that's 500,000 threads that are going to be live on your back end. Now let's say 2 of those users are the same person/account; that means two of your threads are going to be accessing the same information at the same time. – Devarsh Desai Aug 19 '14 at 04:09
  • 1
    This is where you're going to have to worry about concurrency as well. What if both individuals withdraw $500 at the same time? and there's only $500 in the account. You need to ensure critical sections of your code (which are tightly coupled with CRUD operations) are accessed very carefully and precisely as well. If you don't have intensive CRUD operations, then you generally should be good to go for concurrency control! :-) Please let me know if you have any questions! – Devarsh Desai Aug 19 '14 at 04:11
  • Very true! I'm thinking all the data being in the datastore, as long as I model it correctly with entity groups and transactions, i should be good i think. – Creos Aug 20 '14 at 02:58