Transaction management

[sbhatt]

Hi all,
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 .

[pathangi]

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.

[sbhatt]

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

[constv]

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.

[pathangi]

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....

[constv]

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.)

[al0]

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.

Regards,
Oleksandr

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.)

[constv]

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.

[al0]

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.

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.

[sbhatt]

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....

Wot abt the case where ,if exception is raised in AP1 ,The transactions in AP1
along with AP2 has to be rolled back