If Write latency is not an issue do a double defer to a function that then does each write as a defer.
This will allow you retries per op. From: [email protected] [mailto:[email protected]] On Behalf Of Alfred Fuller Sent: Sunday, August 05, 2012 10:30 PM To: zorro Cc: [email protected]; Robert Kluin Subject: Re: [google-appengine] HR datastore batch put Correct, you cannot rely on them being atomic outside a transaction. On Sun, Aug 5, 2012 at 7:23 PM, zorro <[email protected]> wrote: So to summarize the above mess, If I get it right: Batch put for entities from the same entity group is not atomic. Right? Why can not somebody say it? On Monday, March 14, 2011 6:52:55 PM UTC+1, Alfred Fuller wrote: Batch put is not atomic. When using a batch put across entity groups it is very important to make sure the operation is idempotent (for example by not using auto id allocation) as retrying a failed batch put may produce duplicate/orphaned entities (if some succeed or some fail). On Tue, Mar 8, 2011 at 10:29 PM, Robert Kluin <[email protected]> wrote: Hi Matija, The batch-put gets 'parallelized,' that is part of the reason I do not think the put (across multiple entity groups) will be able to be atomic; I don't think you'll be able to figure out which entities did or did not get written if you get an exception. Unless, of course, the app engine datastore guys are working on cross-entity group nested transactions. Of course, then you would probably lose some of the performance benefits of the batch put being parallelized. Robert On Tue, Mar 8, 2011 at 06:07, Matija <[email protected]> wrote: > Hi Robert, > if you think of batch put as simple code helper for multiple entity put > statement everything is pretty clear. > But because latency for single and batch put is almost same batch put is not > simple code helper. I don't ask for some kind of multiple entity group > serialization isolation level. I ask if HR datastore batch put has atomicity > guarantee or not. > After every successful put statement I am able to get entity key for every > stored entities but I don't need this information very often. I think that > it would be nice to have in any kind of async/no response way that they can > provide atomic batch put statement. I think that this paxos/transactional > log replication/'jada jada' arhitecture provides means for this very > interesting database concept. Or maybe I am wrong. So wrong :D > > -- > 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] <mailto:google-appengine%[email protected]> . > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- 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] <mailto:google-appengine%[email protected]> . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- 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. -- 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.
