This week's book giveaway is in the OCAJP forum.
We're giving away four copies of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) and have Khalid A Mughal & Rolf W Rasmussen on-line!
See this thread for details.
Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Idempotent methods

 
Pankaj Kumarkk
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that a idempotent method can be invoked multiple number of times without any side effect.


My question is in what scenarios should i give idempotent behavior?

e.g let's say you have a method which debits a saving account by x dollar amount.
Now this method can be called multiple times in 2 scenarios:
1. User does the debit action twice.
Action 1: User debit 100$
Action 2: User again debits 100$

2. The client software invokes the debit method multiple times in response to a single user request. The client would do it in case of unreliable messaging(ie it doesn't get a confirmation that the method invocation was successful)

I think only in scenario 2 we should give idempotent behavior. In scenario 1 those are 2 discrete user actions and thus are separate.

Please comment.

In HeadFirst servlets it says that user may click the submit button multiple times by mistake and we should ensure idempotent behavior so that this multiple clicks doesn't give wrong behavior. I think in this scenario, server should not be responsible for providing idempotent behavior(as it can't make out that multiple request are due to double clicking a submit button. Each HTTP Request is not way related to another and thus server has no way to determine that it needs to give idempotent behavior now)
In this scenario it should be client which should somehow disallow user from multiple clicks(e.g by disabling the button on first click)

Please comment
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13071
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A method which changes a resource can not by definition be idempotent.

See this Wikipedia article.

A GET which returns the current balance of the savings account should certainly be idempotent.

Bill
 
Pankaj Kumarkk
Ranch Hand
Posts: 112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bill,
I agree with you. My question was the scenarioebs in which we should/shouldnot give idempotent behavior. I think you would agree that in real world applications there will always be methods which will change resource state(for example a debit method)
It will be helpful if you can comment on the specific question.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic