On Thu, Oct 22, 2009 at 12:44 AM, Patrizio Munzi <[email protected]>wrote:
> Hi Max, > > I've just read your new post and I've got two questions. > 1) should we discuss your new posts in this mailing list or in the blog? > > Since you haven't answer my first question yet, :-P, I'm going to ask my > second question in both ways. > I'd rather have these discussions on the blog, but since I don't see your question posted on the blog I'll answer it here. > > 2) Before your new post the only way I knew for transaction isolation was > using the JDOCanRetryException (or at least we'll use it as soon as the bug > fix about it will be released), now we've got also this > JDOOptimisticVerificationException. Now, I can imagine the difference > between them but I'd like to know what's the best way to deal with both of > them. I mean, should we use both of them? Using the JDOCanRetryException > mechanism shouldn't be need of the JDOOptimisticVerificationException. > > A ConcurrentModificationException wrapped in a JDOCanRetryException is the result of 2 concurrent updates to the same entity group. A JDOOptimisticVerificationException is the result of interleaved updates to the same entity. It's entirely up to you to decide how you want to handle these. If you're not concerned about users making updates based on out-of-date information then you probably don't want to use @Version (in which case you'll never get JDOOptimisticVerificationException) and you probably want to automatically retry when you get a JDOCanRetryException whose cause is ConcurrentModificationException. If you always want to ensure that users are making updates based on up to date info then you probably want to use @Version and you probably want to let both JDOOptimisticVerificationException and ConcurrentModificationException propagate back to the user. I'm hard-pressed to think of a scenario where you would be interested in one but not the other, but if such a scenario exists then the flexibility is there. I admit it would have been nice if we threw JDOOptimisticVerificationException in both cases, but JDOOptimisticVerificationException extends JDOFatalDataStoreException, and a ConcurrentModificationException is decidedly not a fatal error. Hope this helps, Max > We'd be very grateful if you could clarify this out. > > Thanks > > > Max Ross wrote: > > > http://gae-java-persistence.blogspot.com/2009/10/optimistic-locking-with-version.html > > > > -- > > *Patrizio Munzi* > Product Specialist > Viale Bruno Buozzi, 19 - 00197 Roma (Italy) > tel: +39 06 4543 3540 > fax: +39 06 4543 3587 > mobile: +39 393 7195 164 > mail: [email protected] > web: http://www.eris4.com > skype: eris4_munzi > > > > --~--~---------~--~----~------------~-------~--~----~ 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=en -~----------~----~----~----~------~----~------~--~---
<<inline: logo.gif>>
