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 google-appengine@googlegroups.** >>> com <[email protected]>. >>> > To unsubscribe from this group, send email to >>> > google-appengine+unsubscribe@**googlegroups.com<google-appengine%[email protected]> >>> . >>> > For more options, visit this group at >>> > http://groups.google.com/**group/google-appengine?hl=en<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 >>> google-appengine@googlegroups.**com<[email protected]> >>> . >>> To unsubscribe from this group, send email to >>> google-appengine+unsubscribe@**googlegroups.com<google-appengine%[email protected]> >>> . >>> For more options, visit this group at http://groups.google.com/** >>> group/google-appengine?hl=en<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.
