[appengine-java] Re: JDO/JPA Snippets That Work - Optimistic Locking With @Version

[Patrizio Munzi]

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.

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.

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: patrizio.mu...@eris4.com
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 google-appengine-java@googlegroups.com  To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com  For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---

[appengine-java] Re: JDO/JPA Snippets That Work - Optimistic Locking With @Version

[Patrizio Munzi]

Max,

no feedback on this??

BR,
    Patrizio

Patrizio Munzi 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.
  
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.
  
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: patrizio.mu...@eris4.com
web: http://www.eris4.com
skype: eris4_munzi
  
  
  
  


-- 

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: patrizio.mu...@eris4.com
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 google-appengine-java@googlegroups.com  To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com  For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---

[appengine-java] Re: JDO/JPA Snippets That Work - Optimistic Locking With @Version

[Max Ross (Google)]

On Thu, Oct 22, 2009 at 12:44 AM, Patrizio Munzi
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: patrizio.mu...@eris4.com
> 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 google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to 
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---

<>

[appengine-java] Re: JDO/JPA Snippets That Work - Optimistic Locking With @Version

[Patrizio Munzi]

Hi Max,
thanks for the answer.

By the way, I tried to post on the blog but I didn't find a way to do
it.
Could be strange but I've never commented on blogspot and had problem
to do it.
I'd be graceful if you could instruct me.

BR,
    Patrizio

Max Ross (Google) wrote:

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





  
  
  
  
  


-- 

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: patrizio.mu...@eris4.com
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 google-appengine-java@googlegroups.com  To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com  For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---

[appengine-java] Re: JDO/JPA Snippets That Work - Optimistic Locking With @Version

[Patrizio Munzi]

Sorry Max,

I'm an idiot, I forgot to disable NoScript. That was because I didn't
see the comment form on your blog.

Cheers

Patrizio Munzi wrote:

  
  
Hi Max,
thanks for the answer.
  
By the way, I tried to post on the blog but I didn't find a way to do
it.
Could be strange but I've never commented on blogspot and had problem
to do it.
I'd be graceful if you could instruct me.
  
BR,
    Patrizio
  
Max Ross (Google) wrote:
  

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





  
  
  -- 
  
  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: patrizio.mu...@eris4.com
web: http://www.eris4.com
skype: eris4_munzi
  
  
  
  


-- 

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: patrizio.mu...@eris4.com
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 google-appengine-java@googlegroups.com  To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com  For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---