On Friday, July 29, 2011 10:17:30 PM UTC+8, Pol wrote:
>
> Hi Jose,
>
> > 2) There is no fake-real-transaction, for example, one of the other
> uncommon
> > exception that someone could get in the commit() would be Timeout
> exception.
> > With any distributed system, unless you are willing to wait for an answer
>
> > forever, there is always the possibility that you will get a timeout
> before
> > the remote system responds with the result of the operation you requested
>
> > (this is true in all databases), what GAE warranty is that the
> transaction
> > either commits successfully or it does not, so if you implement some
> retry
> > logic in transactions, having it idempotent will warranty you don't do
> the
> > transaction twice.
>
> Just to be sure, are you saying that for a timeout exception the
> transaction has actually been committed or not? In other words, should
> a Timeout exception be dealt with the same way a
> TransactionFailedError is?
>
No. I believe he was saying if you get a timeout it just means you didn't
get a response
back in time. So the transaction could have completed or failed. You don't
know.
What you can be certain of is either everything in the transaction succeeded
or failed.
>
> I observe Timeout exceptions now and then where there is too much
> contention on the same entity group. But I've only seen a
> TransactionFailedError once in 2 months.
>
> I get TransactionFailedError quite a bit.
The transaction could not be committed. Please try again.
Traceback (most recent call last):
File
"/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py",
line 702, in __call__
handler.post(*groups)
File
"/base/python_runtime/python_lib/versions/1/google/appengine/ext/deferred/deferred.py",
line 269, in post
run(self.request.body)
File
"/base/python_runtime/python_lib/versions/1/google/appengine/ext/deferred/deferred.py",
line 131, in run
return func(*args, **kwds)
File
"/base/python_runtime/python_lib/versions/1/google/appengine/ext/deferred/deferred.py",
line 174, in invoke_member
return getattr(obj, membername)(*args, **kwargs)
File
"/base/data/home/apps/q-tracker/0-9-9-9.352045897303914982/qtrack/models/contract.py",
line 268, in defer_create_worksheet
db.run_in_transaction(contract.create_worksheet,start_of_week(week))
File
"/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py",
line 2187, in RunInTransaction
DEFAULT_TRANSACTION_RETRIES, function, *args, **kwargs)
File
"/base/python_runtime/python_lib/versions/1/google/appengine/api/datastore.py",
line 2294, in RunInTransactionCustomRetries
'The transaction could not be committed. Please try again.')
TransactionFailedError: The transaction could not be committed. Please try
again.
But this is running in a deferred task, and the task is automatically put
back into the queue, so I know it will eventually get there.
I am running on M/S.
Rgds
Tim
> > But as I said before, this exceptions are uncommon and it would be good
> to
> > know what are you doing inside the transaction that is causing those
> > transactions. Timeout exception could be related to master slaves issues
> (in
> > a M/S app) this could go away by migrating to High replication datastore.
>
>
> I'm using the HR datastore already, but I'm not surprised with the
> Timeouts as in my case there can sometimes, but rarely, be close to 10
> transactions / seconds on the same entity group.
>
> > Hope this helps clarifies some points.
>
> Thanks much for your detailed answers indeed!
>
> - Pol
>
--
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/-/5x_K_zD-N50J.
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.
