New issue 36 by bowman.joseph: Wrapper for retry on timeouts for db.
operations (look at hooks?)
http://code.google.com/p/gaeutilities/issues/detail?id=36
While ROTModel handles timeouts for db.Model, it doesn't handle it for
operations like db.put or db.delete.. A wrapper for that should be built as
well.
With the problems that are happening for get_or_insert and get_by_keyname
on ROTModel, looking at implementing hooks to retry on timeout for all
datastore operations may be a more elegant solution.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
Looks like hooks would be the way to go on this. Not sure I have the time
to invest
in this right now however. Right now, just brainstorming on how I'd would
consider
implementing it.
PreCallHook, push
any type of call - check memcache and see if there are entities that need
to be
pushed down to the datastore, because their writes encountered a timeout
(they get
there below) Also check for failed deletes
PostCallHook, and I'd push it. Make sure you set the hook to only work on
the
datastore. Then do the following
call = put - catch timeout exception, store entity in memcache.
call = delete - catch timeout exception, store key in memcache so it can be
deleted
call = get - catch timeout exception, retry
Concerns are
- How to catch the exception in postcallhook, is it even possible or does
raising
the timeout exception bypass the hook?
- How to handle the retries on read and not throw an endless loop if the
datastore
is just plain unavailable. Need something like ROTModel that loops 3 times,
exponationally increasing the time between retries (first 0 sec, second 1
sec, third
2 sec, raise timeout exception).
Comment #2 on issue 36 by bowman.joseph: Wrapper for retry on timeouts for
db. operations (look at hooks?)
http://code.google.com/p/gaeutilities/issues/detail?id=36
not going to do this.. potentially too heavy, and a bit much of an
incursion into
what the apps built on top of it may require. Instead, going to finish off
ROTModel.