Reputation: 805
I'm making a website with google app engine, but I have a question about the server-side servlets and how they inter act with the datastore database.
Basically, it comes back to the traditional race condition of read-modify-write; i.e. I'm reading an entity out of the datastore, possibly updating it, and then writing the update if there is one.
Basically, can I synchronize access to the datastore? Do I need to? From what I understand, the server can spawn as many instances of my servlets as it likes; I'm using static methods in my 'behind-the-scenes' stuff so I did think I could synchronize the static methods with a static lock object.
Basically, I don't know what defences against race conditions/etc I do/don't need to take. If there's a handy guide somewhere, that'd be great, but I can't seem to find one.
Upvotes: 1
Views: 458
Reputation: 340723
I don't know GAE and their datastore, but in standard servlets the container creates exactly one instance of each servlet and accesses that servlet concurrently. This doesn't change much in your problem.
Synchronizing access to your datastore is a bad idea. First of all this will quickly become a bottleneck as only a single client will be allowed to access database while all others will have to wait. This is unacceptable. Also your solution will break if your application is deployed on multiple servers. synchronized
blocks are not clustered.
What are you are looking for are transactions - and it seems like App Engine Datastore supports them.
Upvotes: 1
Reputation: 111
No synchronized
strategy will help you here because it is not (only) many instances of the servlet that can be spawned by GAE, but many different VMs as well.
For solving your basic question on preventing consistency problems with datastore, you'll have to access your data in atomic transactions. Check here: Transactions
Upvotes: 1