-
1. Re: Diff Transactions On Diff Apps On Diff VMs (Phorum)
Author: Mark Little
Date: 02-23-05 09:10
> Just want to know wether ArjunaTS supports following scenario
> or not?
>
> -- I've one application say mainApp through which I'm calling
> a third party webservice. Lets say this third party app as
> 3pApp.
>
> -- This 3pApp is stroing all user related data for the
> mainApp. mainApp will just have only userid, which i need to
> pass to 3pApp for any actions (updating user info, deleting
> user info and so on...)
>
> -- Now on some action of mainApp, I need to start a
> transaction, whill will remove the user info from 3pApp and
> then make some changes into mainApp database. I dont have
> access to 3pApp transactions. Steps of action will be first
> remove user from 3pApp and then make changes in mainApp
> database. Suppose removal of user info from 3pApp returns
> success, but mainApp throws some exception, then i need to
> rollback 3pApp user removal action.
>
> -- As i dont have control to 3pApp transactions, I cant call
> rollback on it. Moreover, two action - one on 3pApp and another
> on mainApp - should be in one transaction initiated by
> mainApp.
>
> -- Does ArjunaTS address this requirement? If so how? Please
> let me know...
First it depends what you mean by 3pApp's transactions. If they are handled via JDBC, then ArjunaTS can be used to manage this scenario automatically. We provide a transactional JDBC driver that sits inbetween your application and the real JDBC driver and ensures that all transactions that flow through the driver instance are provisional and only made permanent when/if the enclosing global transaction (which ArjunaTS controls) commits.
If you truly have no control over what 3pApp does in terms of transaction management, then you're into the realm of extended transactions. The WS-BusinessActivity specification that ArjunaTS complies with, defines one such extended transaction protocol based on a model called Sagas. In this model, participants in the "transaction" actually do their work immediately (get locks, make updates, release locks etc.) and if the "transaction" needs to rollback (as in your scenario), a compensation transaction is fired off. It is the responsibility of this compensator to try to restore the system to some application specific definition of consistent. Obviously it can't guarantee to restore the state of the system to that which existed prior to the execution of the original "transaction", but that may be the penalty you pay for relaxing the ACID properties. Furthermore, it may not be necessary to restore it to precisely that state. You might want to check out http://www-106.ibm.com/developerworks/webservices/library/ws-comproto/ and http://www.sys-con.com/webservices/articleprint.cfm?id=587 for more information.
To answer your question though: yes, ArjunaTS supports the above scenario as well. You may have to provide your own compensator, but we have some examples with the current product and are working on providing tools to assist in the construction of new implementations.
Does this answer your question?