Kandula2 failure use-cases

[Dobri Kitipov <kd...@gmail.com>]

Hi everybody,
I am interested about some failure use cases which can occur into a WS
Transaction.
If some has some information it will be appreciated

The use cases:

1) What will happen if a WS goes down during the 2PC of the WS TX? What
about if it has succeeded to vote prepared?
If, for example, all WS have voted "prepared", finally commit will be
invoked. How the WS that became unavailable in this specific moment will be
treated? Will it receive the SOAP message to commit when it is again up and
running? Or rollback will be invoked after the WS Transaction?


2) Another interesting scenario is when we have the Coordinator service down
during a WS TX? What will happen then?
Let's say we have 2 WS. The WS1 succeeded to commit but just before to
invoke "Commit" to WS2 AtomicTransactionCoordinator fails. What will happen
with the WS TX?

I will make some tests when i find some time top do so and then will post
the results.

Thank you in advance guys!

Re: Kandula2 failure use-cases

[Hannes Erven <ha...@erven.at>]

Hi Dobri,


I'm not an Kandula 2 expert, but I feel your questions are not product 
specific but rather general WS-Transaction related, so I'll give it a shot.


> 1) What will happen if a WS goes down during the 2PC of the WS TX? What 
> about if it has succeeded to vote prepared?

A WS that reported "prepared" should already have the information about 
the transaction stored reliably, so that it may resume its participation 
once it comes up again.
The coordinator of the atomic transaction will repeatedly try to 
transmit the final "commit" notification to this participant until it 
succeeds (or some configured timeout stops them).


> Or rollback will be invoked after the WS Transaction?

This is impossible - the coordinator notifies all participants at the 
same moment of the "commit". Even if some participants cannot be 
immediately reached, the coordinator cannot redecide since the 
participants that were reachable already have permanently committed and 
left the transaction.



> 2) Another interesting scenario is when we have the Coordinator service 
> down during a WS TX? What will happen then?
> Let's say we have 2 WS. The WS1 succeeded to commit but just before to 
> invoke "Commit" to WS2 AtomicTransactionCoordinator fails. What will 
> happen with the WS TX?

Before sending out commit/rollback notifications the coordinator also 
will reliably store its transaction result. As soon it comes up again, 
it will resume its operation and notify the other participants.

If it doesn't come up again, then yes, there is a problem: the 
transaction on WS2 will hang forever, and also the user doesn't get a 
confirmation back.


> I will make some tests when i find some time top do so and then will 
> post the results.

As far as I know neither Kandula_1 nor Kandula_2 reliably store 
transaction metadata away, so if they go down they forget about all 
running transactions. This is definitely something to improve ;-)


-hannes

---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org