Does Being Stateless Imply Being Idempotent

After reading the BEA Understanding Object Clustering document (there is something I don't understand. The document says:

Stateless EJBs

: When a home creates a stateless bean, it returns a replica-aware EJBObject stub that can route to any server on which the bean is deployed. Because a stateless bean holds no state on behalf of the client, the stub is free to route any call to any server that hosts the bean. Also, because the bean is clustered, the stub can automatically fail over in the event of a failure. The stub does not automatically treat the bean as idempotent, so it will not recover automatically from all failures. If the bean has been written with idempotent methods, this can be noted in the deployment descriptor and automatic failover will be enabled in all cases.

But surely all stateless EJBS must be idempotent. How can you not be idempotent without state?

Not enough. You need stateless and side-effect free to imply idempotent. Actually, side-effect-free is enough - state is just one kind of side effect.

What about one that returns a truly-random number? (Perhaps by getting the number from some hardware device)

Maybe this is an example of what they are talking about - in general terms a stateless component that communicates with a stateful component. It is quite common to use stateless EJBs to encapsulate business logic, and for these to access entity beans to deal with persistent data. The thing is I can't see why this would be a problem - since the stateless bean has to access the stateful component for each invocation, surely it doesn't matter where or on which cluster member each invocation of the stateless component runs. I still don't really understand what they are saying!

Would a truly random number generator be idempotent? Could you use it as if it were? It's not, because each time you call it, it returns a different number. One could say that it is, by saying that it's a function of the current time, and therefore a second call would be made at a different time and get a different number. In a practical sense, as an EJB, you should call it idempotent, because you can safely call it any number of times and freely use the result of the last call. In other words, no "damage" is done by making a call and discarding the result.

"Transfer $200 from savings to checking" can easily be implemented as a stateless call. But it's not idempotent: If it worked, you don't want to do it again.

Perform transaction 2747262 transferring $200 could be idempotent.

Manipulating real-devices can be stateless but not idempotent. Ask a lever to move down 2 inches requires no state but does not give the same results.

OK - I understand now. What they are saying is that in the event of failover you have two options:

don't mark the methods as idempotent, in which case it may still fail. (Executed at most once).
Mark the method as idempotent, in which case it could have been executed before the failover then again afterwards. (Executed at least once).

Thanks for your examples, it's so obvious now I know. ;-) Though you have answered my question, I will leave this page up as it may help others.

[See IdempotentDesign]

Summary

A middle tier component can be stateless in its relationship with the client, while participating in idempotent or non-idempotent operations on the persistent store side. The seeming paradox (stateless but not idempotent?) goes away when we bring back the context of the three tier architecture.