One possible consideration - when you raise multiple tasks, do you do so in a single call to the task queue API (batch put) or multiple calls? If the latter, a great test would be to change to batch put and see if the problem goes away.
On Oct 28, 11:29 pm, hawkett <[email protected]> wrote: > Hi Matija, > > I can see your use case - you want to make sure that either all > tasks get raised, or none. I can also see your worry - that tasks are > actually being *fired* before the transaction is complete. I agree > this would be a completely incorrect situation. I also transactionally > raise multiple tasks, but I always have a datastore operation in > conjunction (and use python) - I haven't encountered this issue of > tasks being fired before the transaction completes, but I wonder if > google has made the assumption that a transaction will always contain > a datastore operation, and perhaps their logic is misbehaving if it > does not? > > An example of how this might happen is if their logic is waiting for a > counter of outstanding db operations to reach 0 before raising tasks. > This would be flawed logic. Thanks, > > Colin > > On Oct 28, 8:21 am, Matija <[email protected]> wrote: > > > > > > > > > I am not saving any entities but I am putting more than one task in > > queue. It depends of the data that current task is processing. Let's > > say two tasks (always less then five). > > > At the end of 'transaction' I will have two tasks in queue or none. > > > This usually works, but sometimes I get this > > ConcurrentModificationException exception. Complete application chunk > > works eventually because task with execute again and will finish > > correctly, but it would be nice to understand this exception so that I > > can avoid it. > > > On Oct 28, 1:58 am, Tim Hoffman <[email protected]> wrote: > > > > If you are not saving any entities why are you using a transaction to > > > put the task into the queue. > > > > The idea of a queuing a task transactionally is that the task doesn't > > > get fired if the transaction fails (ie you save of entities fails). > > > > Seems completely redundant > > > > Rgds > > > > T > > > > On Oct 21, 11:18 pm, Matija <[email protected]> wrote: > > > > > Hi, > > > > I am > > > > usinghttp://code.google.com/appengine/docs/java/taskqueue/overview.html#Ta... > > > > way to enqueue two tasks in transaction. But I am not saving any > > > > datastore entities. I am using objectify. > > > > > I got this message: > > > > > java.util.ConcurrentModificationException: too much contention on > > > > these datastore entities. please try again. > > > > at > > > > com.google.appengine.api.datastore.DatastoreApiHelper.translateError(Datast > > > > oreApiHelper.java: > > > > 39) > > > > at > > > > com.google.appengine.api.datastore.DatastoreApiHelper.makeSyncCall(Datastor > > > > eApiHelper.java: > > > > 75) > > > > at > > > > com.google.appengine.api.datastore.TransactionImpl.makeSyncCall(Transaction > > > > Impl.java: > > > > 44) > > > > at > > > > com.google.appengine.api.datastore.TransactionImpl.makeSyncCall(Transaction > > > > Impl.java: > > > > 52) > > > > at > > > > com.google.appengine.api.datastore.TransactionImpl.commit(TransactionImpl.j > > > > ava: > > > > 64) > > > > > When this happened only one task needed to be added to queue, so why > > > > this error ? -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
