On Thu, Oct 22, 2009 at 12:44 AM, Patrizio
Munzi
<patrizio.mu...@eris4.com>
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
