Thanks Broc, that explanation helped a lot. Some more questions below: On Wed, Jan 4, 2012 at 10:49 AM, Broc Seib <broc.s...@gmail.com> wrote:
> Suppose you have two threads calling your code snippet below, both > trying to update the same entity. The first thread to call commit() in > your transaction wins. The second thread will throw a > ConcurrentModificationException upon calling commit(). > Ah, I understand now. I was under the impression that the whole datastore gets locked so that other threads can't even begin their transactions when another transaction is executing. From a performance point of view I am glad that is not happening :) Now, why doesn't the ShardingCounter example do a transaction retry? It's the second example in this document: http://code.google.com/appengine/articles/sharding_counters.html Secondly, is there a way to lock on certain Entities so that other threads will block if they are going to work on the same entities? That seems like a better approach to mean than implementing a retry logic. > > Your application should take the necessary action if another thread > has already written data to the spot you wanted. In my case, I did not > want to occupy the same spot, so I took that exception as a desired > failure to simulate a "unique constraint". > Thanks for the tip on implementing "unique constraint". Glad I posted this thread. cheers, -- Harshad RJ http://lavadip.com -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
