I should have mentioned that the re-fetch should be done in a transaction, which should take away the "eventually" part since from what I've gathered I think you're reading directly from the master transaction log. As for the continuous timing out due to datastore issues then you'd have to fallback to the task queue as Joshua has stated. It's not a perfect solution but oh well.
On Thu, Jul 28, 2011 at 10:48 AM, Joshua Smith <joshuaesm...@charter.net>wrote: > > > 6.) if exception is generated, then re-query the entity if the entity has > "our" unique timestamp in its list then the transaction really did succeed, > if not then the transaction really did fail. > > Could work, except that you'll need to do #6 with a task queue task, > because in the case of an exception, they only say it might "eventually" > make it into the database. So if you just requery and it isn't there, then > you don't know that it didn't succeed… you just know it didn't succeed > *yet*. And since the exception which leads to this problem is > "InternalError", and we know when those start coming up you can expect to > see them continue for a long time, you're going to have a lot of stuff in > that queue. > > So that means you need to throw this check into the task queue, and keep > checking it for a while. Which probably means you need to have a really big > list of "recent" transactions (not just 10). > > This hack is similar to what I suggested, which is to create a transaction > record in the database as a child of the entity you are updating in the > transaction. When you get the exception, you wait a while (how long???) and > then see if the transaction record exists using an ancestor query. If it > does, then the transaction succeeded, and if not, then it didn't. This > avoids having to add goofy hacky attributes to the thing you are updating, > and in principle, you can schedule a task to delete any transaction records > for successful transactions (or periodically sweep up old ones with a cron > job). > > So, I suppose, it is possible to create a framework that can really do > transactions using the building blocks GAE has provided us, but to say that > GAE supports transactions on its own is a stretch. > > -Joshua > > -- > 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. > To unsubscribe from this group, send email to > google-appengine+unsubscr...@googlegroups.com. > 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 google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
