Ah, thanks.  So if I knew how many servers my cloud is made of then I should 
use that number for my MAX_RETRIES.  ;-)

I'm curious about how others are handling the exceptions.  The 
JDOCanRetryException is subclassed by other exceptions that don't seem like 
things I'd want to retry, but perhaps I don't understand the subtleties.  
Here's what I'm doing; it's an AOP gizmo, courtesy of Spring.  The 
pjp.proceed() is where my transaction wrapped method is called.  Looks clunky 
to me, given that it's not readily apparent why it's doing what it does.

    public Object retry(final ProceedingJoinPoint pjp) throws Throwable {
        this.log.debug("called");

        JDOException exception = new JDOException("oops; too many retries");

        int retryCount = 0;

        while (retryCount++ < this.maxRetries) {
            try {
                return (pjp.proceed());
            }
            catch (final JDOUserException ex) {
                exception = ex;

                break; // fail
            }
            catch (final JDOCanRetryException ex) {
                exception = ex;

                // retry
            }
            catch (final JDOException ex) {
                exception = ex;

                /**
                 * to quote Google's documentation: If any action
                 * fails due to the requested entity group being in
                 * use by another process, JDO throws a
                 * JDODataStoreException or a JDOException, caused by a
                 * java.util.ConcurrentModificationException.
                 */
                if (!(ex.getCause() instanceof ConcurrentModificationException))
                    break; // fail

                // retry
            }

            this.log.debug("retryCount: {}, exception: {}",
                    Integer.valueOf(retryCount),
                    ExceptionUtils.getFullStackTrace(exception));
        }

        throw (exception);
    }


ted stockwell wrote:
> 
> On Nov 17, 2:59 pm, Rusty Wright <[email protected]> wrote:
>> Is there some way to pause before retrying the database transaction?  If you 
>> don't, then it seems to me that the processes that are banging into each 
>> other are going to keep failing.  I'd like to add a pause for a random 
>> amount of time in the catch block.
>>
> 
> It is not necessary to pause before retrying because if a transaction
> fails with a 'RetryException' it is only because some other
> transaction was committed and that other transaction made some changes
> that are incompatible with the failed transactions changes.
> 
> So... suppose you kick off 10 transactions at once.
> At *most* only 9 of those transactions will fail with a
> RetryException.
> If you retry those 9 then at *most* 8 will fail, and so on....
> 
> 
> --
> 
> You received this message because you are subscribed to the Google Groups 
> "Google App Engine for Java" 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-java?hl=.
> 
> 

--

You received this message because you are subscribed to the Google Groups 
"Google App Engine for Java" 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-java?hl=.


Reply via email to