Mar 16th, 2009, 06:06 AM
I have a service method which is transactional.I have two calls
1.a call to update a local Mysql db.
2.Call a web service to update another database
My requirement is to make both of these in a transactional.i.e if one fails
both of them should fail ,or else if both of them are success.both of them should commit
How can i accomplish this?.
thanks in advance for any help in this regard .
Mar 17th, 2009, 09:11 PM
I am not clear what exactly you say. When you say webservice call, is it something happens outside spring container. In such case, i guess it is not possible. Transaction can be controlled only if the components are part of the same spring container.
Mar 17th, 2009, 11:41 PM
AP1 ----> DB1
AP2 ----> DB2
Application 1(AP1) updates DB1,Application 2(AP2) updates DB2.
I send a web service call from AP1 to A2 to update DB2.AP1,AP2 may reside on
same server or different servers.
My problem is to achieve transaction control in the case:
AP1 updates DB1 and web service call from AP1 to AP2 updates DB2
If this is not possible,can u suggest any suitable workaround ?
Thanks in advance
Mar 18th, 2009, 09:31 AM
Web services, by definition, are external black boxes that your local application has no control of but should only be able to send requests to and receive responses from based on a published contract. If you are designing a system where you assume that you should have control over both sub-systems, than, perhaps, a WS approach is not applicable.
Mar 18th, 2009, 09:58 AM
Call to Ap2 is webservice and you dont have control over it...read the soap header message from AP2 call
and handle the exception in case of error from AP2... this way you can control transaction on AP1....
Last edited by pathangi; Mar 18th, 2009 at 10:05 AM.
Mar 18th, 2009, 10:11 AM
pathangi, you must have replaced your last post... The following was my response to what you had removed:
When you deal with web services, it is not very appropriate to assume anything about the implementation details of the web service, e.g. the technology, the data source behind it, etc. You are assuming that there is a database there, which would be indeed the case in this example, but, it is not a correct way to approach web services, really. Even if you write the client and the WS (with everything behind it) yourself, the main point about a WS is that any client does not need to, and should not assume anything about what's inside. The clients only should be aware of what they can ask for, and what they can expect to get back. The should not assume any "commits" that happen behind the WS interface. That's my take on it. (I agree with what you said in the final edit of your last post.)
Last edited by constv; Mar 18th, 2009 at 10:19 AM.
Mar 18th, 2009, 10:48 AM
H-m-m, strictly speaking it is not exactly so - there are some standards defining WEb Service participation in a transaction, you may want to look here: http://www.ibm.com/developerworks/we...y/ws-transjta/
and here http://en.wikipedia.org/wiki/List_of...e cifications
If this info is applicable to this particular case is another matter.
Originally Posted by constv
Mar 18th, 2009, 11:23 AM
Olexandr, thanks for the links. Without a doubt, such transactionality may be achieved, but that would require introducing additional external coordinators and making the participating apps aware of the coordinator context, as the article describes. Not sure if that was what sbhatt had in mind.
Mar 18th, 2009, 11:29 AM
Exactly, it is why I have written "f this info is applicable to this particular case is another matter.". BTW, I'm now faced with a requirement to include Web-services in a transaction in more or less generic way (we provide services that customers should be able call transactionally), but have not find satisfying solution yet.
Originally Posted by constv
Mar 18th, 2009, 11:53 PM
Wot abt the case where ,if exception is raised in AP1 ,The transactions in AP1
Originally Posted by pathangi
along with AP2 has to be rolled back