It won't help avoid the collision. It will let you keep track of previous
transactions.
On Jul 29, 2011 8:20 PM, "vlad" wrote:
>
> Joushua,
>
> I was thinking of putting child entities approach as well. The question is
does writing a new child entity blocks the whole entity group? If answer is
ye
Joushua,
I was thinking of putting child entities approach as well. The question is
does writing a new child entity blocks the whole entity group? If answer is
yes. Then you get no benefit from that other than keeping meticulous track
of what is happening. I would consider that approach if it l
Hi Joshua,
As robert said, making a process idempotent depends mostly on the app logic
and data model. IMO for the example case you need more of a context of how
the counter is been use to make the use of the counter in a transaction
idempotent. (remember: the example just illustrates how to ma
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
> 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
The problem is that google transactions can report an exception, and then go
ahead and succeed anyway.
So the docs recommend that you only write idempotent transactions, which is a
completely silly suggestion. I've yet to see a single example of how one might
write an idempotent transaction.
If you always get modify put within a transaction how would it be
unreliable?
Rgds
Tim
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/mP_8kv_
Can you give an example? Because that approach would seem to be unreliable in
a two-writer scenario.
On Jul 26, 2011, at 10:11 PM, Robert Kluin wrote:
> Well, I generally put revision numbers on my entities. In my
> transctions, before the update, I check that the revision number
> currently o
Well, I generally put revision numbers on my entities. In my
transctions, before the update, I check that the revision number
currently on the entity matches what I expect. If it doesn't then I
know the update is out-of-date.
There are other solutions too, depending on the app and data model.
On this topic, nobody ever answered this question:
> http://code.google.com/appengine/docs/python/datastore/transactions.html
>
> First it says, "Make sure your transactions are idempotent" and then it gives
> an example which isn't.
>
> I'm not sure it's possible to do the task in that example
Hi Pol,
What this meas is that even if a transaction throws an exception this does
not means the transaction failed, thats why you need to make your datastore
transaction idempotent. So if you retry a transaction because it throws an
exception, your transaction needs to "check" if the last
tra
Hi Pol,
Generally you will probably want to execute it again.
Robert
On Mon, Jul 25, 2011 at 03:53, Pol wrote:
> Hi,
>
> The exception says: TransactionFailedError: The transaction could not
> be committed. Please try again.
>
> The doc at
> http://code.google.com/appengine/docs/python/d
Hi,
The exception says: TransactionFailedError: The transaction could not
be committed. Please try again.
The doc at
http://code.google.com/appengine/docs/python/datastore/transactions.html
says: You can receive Timeout, TransactionFailedError, or
InternalError exceptions in cases where transact
13 matches
Mail list logo
