You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kandula-dev@ws.apache.org by Benjamin Schmeling <Be...@gmx.de> on 2006/05/10 10:53:32 UTC
Writing a custom banking service
Hi,
I am just new with Kandula. I want to write a Banking Service, that can
be part of a Atomic Transaction. My Interface looks like this:
* public boolean debit(String accountNo, String amount);
* public boolean debit(String accountNo, String amount);
* public String getBalance(String accountNo);
* public void commit();
* public void rollback() ;
* public void prepare();
I deployed all transactional services that are needed and put the
client-config.wsdd to the WEB-INF/classes of my Tomcat.
The service is deployed like this:
<service name="DeutscheBankWS" provider="java:RPC">
<requestFlow>
<handler type="soapmonitor"/>
<handler
type="java:org.apache.axis.message.addressing.handler.AddressingHandler" />
<handler type="java:org.apache.kandula.coordinator.at.TxHandler" />
</requestFlow>
<responseFlow>
<handler
type="java:org.apache.axis.message.addressing.handler.AddressingHandler" />
<handler type="soapmonitor"/>
</responseFlow>
<parameter name="allowedMethods" value="*"/>
<parameter name="className" value="de.tud.ao4bpel.samples.banking.Bank"/>
<parameter name="scope" value="application"/>
</service>
My client code is like this:
tm.begin();
sendDebit("20", "1","DeutscheBankWS");
tm.commit();
The SOAP Monitor shows the following Message Scenario:
* activationCoordinator is called and it returns a response
* registrationCoordinator is called and it returns a response
* DeutscheBankWS is called (with the coordination context) and it
returns a response
* registrationCoordinator is called and it returns a response
* completionCoordinator is called and it returns no response
(containing <Commit xsi:nil="true"
xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
* participant is called and it returns no response
* coordinator is called and it returns no response
* completionInitiator is called and it returns no response
Can anyone help me to make this working? Do you need additional details
of the messages or my configuration?
Thanks,
Benjamin
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
Hi Benjamin,
> Yes you are absolutely right. Thanks; after exposing my application as
> Web Service this is working now. But when I call my Web Service the
> second time there is a exception at:
>
> tm.begin();
pls check whether you have properly configured all the handlers for both inflow
and outflow. also pls let me know for what protocol (completion/2PC etc.) the
registration is.
thanks,
--dasarath
>
> The exception is:
>
> AxisFault
> faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
> faultSubcode:
> faultString: The message was invalid for the current state of the activity.
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}stackTrace:The message was invalid for
> the current state of the activity.
> at
> org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
> at
> org.apache.kandula.coordinator.CoordinatorImpl.registerOperation
(CoordinatorImpl.java:63)
> at
> org.apache.kandula.coordinator.RegistrationImpl.registerOperation
(RegistrationImpl.java:31)
>
> This exception occurs when I invoke the second call of my TransactionWS
> where I want to do exactly the same again. In this case there is no
> message to the activcation coordinator but the first messages goes to
> the registrationCoordinator which does not give any response.
>
>
> My workflow is like this:
>
> [BankOne] debit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] debit
> [BankDBMS] after debit amount = 480
> [Bank] closing connection
> [BankDBMS] end
> true
> [BankOne] credit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] credit
> [Bank] closing connection
> [BankDBMS] end
> true
> [CallbackRegistry] registerCallback: timeout= 180000
> [BankDBMS] end
> [BankDBMS] end
> [BankDBMS] prepare
> [BankDBMS] prepare
> [BankDBMS] commit
> [BankDBMS] 480
> [BankDBMS] commit
> [BankDBMS] 520
> [TransactionService] committed
>
> Thanks,
>
> Benjamin
> > Quoting Benjamin Schmeling <Be...@gmx.de>:
> >
> >
> >> Thank you very much for your support (Hannes and Dasarath)
> >>
> >> The example is really that what I needed and I got my Banking Service
> >> working now. The only problem that remains is that the calling of the
> >> commit() operation never returns. When I terminate my TestCase manually
> >> and call it another time, there is a problem with the coordinator and
> >> the transaction cannot be started again. How could I fix this?
> >>
> >
> > I presume you are running your client as a standalone application--
> correct?
> > the commit/rollback operations wait for the COMMITTED/ABORTED messages from
> the
> > coordinator. However, a standalone application cannot receive these
> messages.
> > So the solution is to run your client inside a container like Tomcat where
>
> > kandula has been deployed. That's what I've done in my example code.
> Whenever,
> > we send an async message to which we expect a reply, kandula creates a
> dynamic
> > endpoint-- axis2 does this automatically but for now we have to do it our
> > selves on axis1.x.
> >
> > Earlier on we were able to run standalone apps without trouble b'cos we
> were
> > using sync porttypes but now that we have switched to async, this is no
> longer
> > possible. In fact, the reason you are able to even come this far is b'cos
> > activation and registration still use sync porttypes!
> >
> > thanks,
> > --dasarath
> >
> >
> >
> >> TransactionManagerImpl tm =
> >> TransactionManagerImpl.getInstance();
> >>
> >> getBalance("1","DeutscheBankWS");
> >> tm.begin();
> >> sendDebit("20", "1","DeutscheBankWS");
> >> sendCredit("20", "1","CommerzBankWS");
> >> tm.commit(); <---
> >>
> >> Thanks,
> >>
> >> Benjamin
> >>
> >>> Quoting Hannes Erven <ha...@erven.at>:
> >>>
> >>>
> >>>
> >>>> Hi Benjamin,
> >>>>
> >>>>
> >>>> > * completionCoordinator is called and it returns no response
> >>>> > (containing <Commit xsi:nil="true"
> >>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> >>>> > * participant is called and it returns no response
> >>>> > * coordinator is called and it returns no response
> >>>> > * completionInitiator is called and it returns no response
> >>>>
> >>>> That's OK, since those calls aren't expected to return anything. The
> >>>> "Commit" message just tells the coordinator to commit. Once it has, it
> >>>> sends a message to the completionInitiator containing the result -
> >>>> Commited or Rolled Back.
> >>>> (The same pattern applies to the calls between participant ("prepare")
> >>>> and coordintor.)
> >>>>
> >>>>
> >>> the reply to prepare can be either PREPARED or ABORTED. But both these
> >>>
> >> messages
> >>
> >>> are sent over seperate connections. you should be able to them however.
> >>>
> >>> --dasarath
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
I am using axis1.3 with kandula 0.2. I solved the problem. I had defined
the transaction handler at the request flow of the banking services that
was the problem. Now everything is working fine, thanks!
> Yes you are absolutely right. Thanks; after exposing my application as
> Web Service this is working now. But when I call my Web Service the
> second time there is a exception at:
>
> tm.begin();
>
> The exception is:
>
> AxisFault
> faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
> faultSubcode:
> faultString: The message was invalid for the current state of the
> activity.
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}stackTrace:The message was invalid for
> the current state of the activity.
> at
> org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
>
> at
> org.apache.kandula.coordinator.CoordinatorImpl.registerOperation(CoordinatorImpl.java:63)
>
> at
> org.apache.kandula.coordinator.RegistrationImpl.registerOperation(RegistrationImpl.java:31)
>
>
> This exception occurs when I invoke the second call of my
> TransactionWS where I want to do exactly the same again. In this case
> there is no message to the activcation coordinator but the first
> messages goes to the registrationCoordinator which does not give any
> response.
>
>
> My workflow is like this:
>
> [BankOne] debit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] debit
> [BankDBMS] after debit amount = 480
> [Bank] closing connection
> [BankDBMS] end
> true
> [BankOne] credit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] credit
> [Bank] closing connection
> [BankDBMS] end
> true
> [CallbackRegistry] registerCallback: timeout= 180000
> [BankDBMS] end
> [BankDBMS] end
> [BankDBMS] prepare
> [BankDBMS] prepare
> [BankDBMS] commit
> [BankDBMS] 480
> [BankDBMS] commit
> [BankDBMS] 520
> [TransactionService] committed
>
> Thanks,
>
> Benjamin
>> Quoting Benjamin Schmeling <Be...@gmx.de>:
>>
>>
>>> Thank you very much for your support (Hannes and Dasarath)
>>>
>>> The example is really that what I needed and I got my Banking
>>> Service working now. The only problem that remains is that the
>>> calling of the commit() operation never returns. When I terminate my
>>> TestCase manually and call it another time, there is a problem with
>>> the coordinator and the transaction cannot be started again. How
>>> could I fix this?
>>>
>>
>> I presume you are running your client as a standalone application--
>> correct? the commit/rollback operations wait for the
>> COMMITTED/ABORTED messages from the coordinator. However, a
>> standalone application cannot receive these messages. So the solution
>> is to run your client inside a container like Tomcat where kandula
>> has been deployed. That's what I've done in my example code.
>> Whenever, we send an async message to which we expect a reply,
>> kandula creates a dynamic endpoint-- axis2 does this automatically
>> but for now we have to do it our selves on axis1.x.
>>
>> Earlier on we were able to run standalone apps without trouble b'cos
>> we were using sync porttypes but now that we have switched to async,
>> this is no longer possible. In fact, the reason you are able to even
>> come this far is b'cos activation and registration still use sync
>> porttypes!
>>
>> thanks,
>> --dasarath
>>
>>
>>
>>> TransactionManagerImpl tm =
>>> TransactionManagerImpl.getInstance();
>>> getBalance("1","DeutscheBankWS");
>>> tm.begin();
>>> sendDebit("20", "1","DeutscheBankWS");
>>> sendCredit("20", "1","CommerzBankWS");
>>> tm.commit(); <---
>>>
>>> Thanks,
>>>
>>> Benjamin
>>>
>>>> Quoting Hannes Erven <ha...@erven.at>:
>>>>
>>>>
>>>>> Hi Benjamin,
>>>>>
>>>>>
>>>>> > * completionCoordinator is called and it returns no response
>>>>> > (containing <Commit xsi:nil="true"
>>>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>>>>> > * participant is called and it returns no response
>>>>> > * coordinator is called and it returns no response
>>>>> > * completionInitiator is called and it returns no response
>>>>>
>>>>> That's OK, since those calls aren't expected to return anything.
>>>>> The "Commit" message just tells the coordinator to commit. Once it
>>>>> has, it sends a message to the completionInitiator containing the
>>>>> result - Commited or Rolled Back.
>>>>> (The same pattern applies to the calls between participant
>>>>> ("prepare") and coordintor.)
>>>>>
>>>> the reply to prepare can be either PREPARED or ABORTED. But both these
>>>>
>>> messages
>>>> are sent over seperate connections. you should be able to them
>>>> however.
>>>>
>>>> --dasarath
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
Hi Benjamin,
> Yes you are absolutely right. Thanks; after exposing my application as
> Web Service this is working now. But when I call my Web Service the
> second time there is a exception at:
>
> tm.begin();
pls check whether you have properly configured all the handlers for both inflow
and outflow. also pls let me know for what protocol (completion/2PC etc.) the
registration is.
thanks,
--dasarath
>
> The exception is:
>
> AxisFault
> faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
> faultSubcode:
> faultString: The message was invalid for the current state of the activity.
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}stackTrace:The message was invalid for
> the current state of the activity.
> at
> org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
> at
> org.apache.kandula.coordinator.CoordinatorImpl.registerOperation
(CoordinatorImpl.java:63)
> at
> org.apache.kandula.coordinator.RegistrationImpl.registerOperation
(RegistrationImpl.java:31)
>
> This exception occurs when I invoke the second call of my TransactionWS
> where I want to do exactly the same again. In this case there is no
> message to the activcation coordinator but the first messages goes to
> the registrationCoordinator which does not give any response.
>
>
> My workflow is like this:
>
> [BankOne] debit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] debit
> [BankDBMS] after debit amount = 480
> [Bank] closing connection
> [BankDBMS] end
> true
> [BankOne] credit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] credit
> [Bank] closing connection
> [BankDBMS] end
> true
> [CallbackRegistry] registerCallback: timeout= 180000
> [BankDBMS] end
> [BankDBMS] end
> [BankDBMS] prepare
> [BankDBMS] prepare
> [BankDBMS] commit
> [BankDBMS] 480
> [BankDBMS] commit
> [BankDBMS] 520
> [TransactionService] committed
>
> Thanks,
>
> Benjamin
> > Quoting Benjamin Schmeling <Be...@gmx.de>:
> >
> >
> >> Thank you very much for your support (Hannes and Dasarath)
> >>
> >> The example is really that what I needed and I got my Banking Service
> >> working now. The only problem that remains is that the calling of the
> >> commit() operation never returns. When I terminate my TestCase manually
> >> and call it another time, there is a problem with the coordinator and
> >> the transaction cannot be started again. How could I fix this?
> >>
> >
> > I presume you are running your client as a standalone application--
> correct?
> > the commit/rollback operations wait for the COMMITTED/ABORTED messages from
> the
> > coordinator. However, a standalone application cannot receive these
> messages.
> > So the solution is to run your client inside a container like Tomcat where
>
> > kandula has been deployed. That's what I've done in my example code.
> Whenever,
> > we send an async message to which we expect a reply, kandula creates a
> dynamic
> > endpoint-- axis2 does this automatically but for now we have to do it our
> > selves on axis1.x.
> >
> > Earlier on we were able to run standalone apps without trouble b'cos we
> were
> > using sync porttypes but now that we have switched to async, this is no
> longer
> > possible. In fact, the reason you are able to even come this far is b'cos
> > activation and registration still use sync porttypes!
> >
> > thanks,
> > --dasarath
> >
> >
> >
> >> TransactionManagerImpl tm =
> >> TransactionManagerImpl.getInstance();
> >>
> >> getBalance("1","DeutscheBankWS");
> >> tm.begin();
> >> sendDebit("20", "1","DeutscheBankWS");
> >> sendCredit("20", "1","CommerzBankWS");
> >> tm.commit(); <---
> >>
> >> Thanks,
> >>
> >> Benjamin
> >>
> >>> Quoting Hannes Erven <ha...@erven.at>:
> >>>
> >>>
> >>>
> >>>> Hi Benjamin,
> >>>>
> >>>>
> >>>> > * completionCoordinator is called and it returns no response
> >>>> > (containing <Commit xsi:nil="true"
> >>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> >>>> > * participant is called and it returns no response
> >>>> > * coordinator is called and it returns no response
> >>>> > * completionInitiator is called and it returns no response
> >>>>
> >>>> That's OK, since those calls aren't expected to return anything. The
> >>>> "Commit" message just tells the coordinator to commit. Once it has, it
> >>>> sends a message to the completionInitiator containing the result -
> >>>> Commited or Rolled Back.
> >>>> (The same pattern applies to the calls between participant ("prepare")
> >>>> and coordintor.)
> >>>>
> >>>>
> >>> the reply to prepare can be either PREPARED or ABORTED. But both these
> >>>
> >> messages
> >>
> >>> are sent over seperate connections. you should be able to them however.
> >>>
> >>> --dasarath
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
I am using axis1.3 with kandula 0.2. I solved the problem. I had defined
the transaction handler at the request flow of the banking services that
was the problem. Now everything is working fine, thanks!
> Yes you are absolutely right. Thanks; after exposing my application as
> Web Service this is working now. But when I call my Web Service the
> second time there is a exception at:
>
> tm.begin();
>
> The exception is:
>
> AxisFault
> faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
> faultSubcode:
> faultString: The message was invalid for the current state of the
> activity.
> faultActor:
> faultNode:
> faultDetail:
> {http://xml.apache.org/axis/}stackTrace:The message was invalid for
> the current state of the activity.
> at
> org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
>
> at
> org.apache.kandula.coordinator.CoordinatorImpl.registerOperation(CoordinatorImpl.java:63)
>
> at
> org.apache.kandula.coordinator.RegistrationImpl.registerOperation(RegistrationImpl.java:31)
>
>
> This exception occurs when I invoke the second call of my
> TransactionWS where I want to do exactly the same again. In this case
> there is no message to the activcation coordinator but the first
> messages goes to the registrationCoordinator which does not give any
> response.
>
>
> My workflow is like this:
>
> [BankOne] debit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] debit
> [BankDBMS] after debit amount = 480
> [Bank] closing connection
> [BankDBMS] end
> true
> [BankOne] credit(1, 20)
> [Bank] opening connection
> [BankDBMS] isSameRM
> [BankDBMS] isSameRM
> [BankDBMS] start
> [BankDBMS] credit
> [Bank] closing connection
> [BankDBMS] end
> true
> [CallbackRegistry] registerCallback: timeout= 180000
> [BankDBMS] end
> [BankDBMS] end
> [BankDBMS] prepare
> [BankDBMS] prepare
> [BankDBMS] commit
> [BankDBMS] 480
> [BankDBMS] commit
> [BankDBMS] 520
> [TransactionService] committed
>
> Thanks,
>
> Benjamin
>> Quoting Benjamin Schmeling <Be...@gmx.de>:
>>
>>
>>> Thank you very much for your support (Hannes and Dasarath)
>>>
>>> The example is really that what I needed and I got my Banking
>>> Service working now. The only problem that remains is that the
>>> calling of the commit() operation never returns. When I terminate my
>>> TestCase manually and call it another time, there is a problem with
>>> the coordinator and the transaction cannot be started again. How
>>> could I fix this?
>>>
>>
>> I presume you are running your client as a standalone application--
>> correct? the commit/rollback operations wait for the
>> COMMITTED/ABORTED messages from the coordinator. However, a
>> standalone application cannot receive these messages. So the solution
>> is to run your client inside a container like Tomcat where kandula
>> has been deployed. That's what I've done in my example code.
>> Whenever, we send an async message to which we expect a reply,
>> kandula creates a dynamic endpoint-- axis2 does this automatically
>> but for now we have to do it our selves on axis1.x.
>>
>> Earlier on we were able to run standalone apps without trouble b'cos
>> we were using sync porttypes but now that we have switched to async,
>> this is no longer possible. In fact, the reason you are able to even
>> come this far is b'cos activation and registration still use sync
>> porttypes!
>>
>> thanks,
>> --dasarath
>>
>>
>>
>>> TransactionManagerImpl tm =
>>> TransactionManagerImpl.getInstance();
>>> getBalance("1","DeutscheBankWS");
>>> tm.begin();
>>> sendDebit("20", "1","DeutscheBankWS");
>>> sendCredit("20", "1","CommerzBankWS");
>>> tm.commit(); <---
>>>
>>> Thanks,
>>>
>>> Benjamin
>>>
>>>> Quoting Hannes Erven <ha...@erven.at>:
>>>>
>>>>
>>>>> Hi Benjamin,
>>>>>
>>>>>
>>>>> > * completionCoordinator is called and it returns no response
>>>>> > (containing <Commit xsi:nil="true"
>>>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>>>>> > * participant is called and it returns no response
>>>>> > * coordinator is called and it returns no response
>>>>> > * completionInitiator is called and it returns no response
>>>>>
>>>>> That's OK, since those calls aren't expected to return anything.
>>>>> The "Commit" message just tells the coordinator to commit. Once it
>>>>> has, it sends a message to the completionInitiator containing the
>>>>> result - Commited or Rolled Back.
>>>>> (The same pattern applies to the calls between participant
>>>>> ("prepare") and coordintor.)
>>>>>
>>>> the reply to prepare can be either PREPARED or ABORTED. But both these
>>>>
>>> messages
>>>> are sent over seperate connections. you should be able to them
>>>> however.
>>>>
>>>> --dasarath
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Yes you are absolutely right. Thanks; after exposing my application as
Web Service this is working now. But when I call my Web Service the
second time there is a exception at:
tm.begin();
The exception is:
AxisFault
faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
faultSubcode:
faultString: The message was invalid for the current state of the activity.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:The message was invalid for
the current state of the activity.
at
org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
at
org.apache.kandula.coordinator.CoordinatorImpl.registerOperation(CoordinatorImpl.java:63)
at
org.apache.kandula.coordinator.RegistrationImpl.registerOperation(RegistrationImpl.java:31)
This exception occurs when I invoke the second call of my TransactionWS
where I want to do exactly the same again. In this case there is no
message to the activcation coordinator but the first messages goes to
the registrationCoordinator which does not give any response.
My workflow is like this:
[BankOne] debit(1, 20)
[Bank] opening connection
[BankDBMS] isSameRM
[BankDBMS] start
[BankDBMS] debit
[BankDBMS] after debit amount = 480
[Bank] closing connection
[BankDBMS] end
true
[BankOne] credit(1, 20)
[Bank] opening connection
[BankDBMS] isSameRM
[BankDBMS] isSameRM
[BankDBMS] start
[BankDBMS] credit
[Bank] closing connection
[BankDBMS] end
true
[CallbackRegistry] registerCallback: timeout= 180000
[BankDBMS] end
[BankDBMS] end
[BankDBMS] prepare
[BankDBMS] prepare
[BankDBMS] commit
[BankDBMS] 480
[BankDBMS] commit
[BankDBMS] 520
[TransactionService] committed
Thanks,
Benjamin
> Quoting Benjamin Schmeling <Be...@gmx.de>:
>
>
>> Thank you very much for your support (Hannes and Dasarath)
>>
>> The example is really that what I needed and I got my Banking Service
>> working now. The only problem that remains is that the calling of the
>> commit() operation never returns. When I terminate my TestCase manually
>> and call it another time, there is a problem with the coordinator and
>> the transaction cannot be started again. How could I fix this?
>>
>
> I presume you are running your client as a standalone application-- correct?
> the commit/rollback operations wait for the COMMITTED/ABORTED messages from the
> coordinator. However, a standalone application cannot receive these messages.
> So the solution is to run your client inside a container like Tomcat where
> kandula has been deployed. That's what I've done in my example code. Whenever,
> we send an async message to which we expect a reply, kandula creates a dynamic
> endpoint-- axis2 does this automatically but for now we have to do it our
> selves on axis1.x.
>
> Earlier on we were able to run standalone apps without trouble b'cos we were
> using sync porttypes but now that we have switched to async, this is no longer
> possible. In fact, the reason you are able to even come this far is b'cos
> activation and registration still use sync porttypes!
>
> thanks,
> --dasarath
>
>
>
>> TransactionManagerImpl tm =
>> TransactionManagerImpl.getInstance();
>>
>> getBalance("1","DeutscheBankWS");
>> tm.begin();
>> sendDebit("20", "1","DeutscheBankWS");
>> sendCredit("20", "1","CommerzBankWS");
>> tm.commit(); <---
>>
>> Thanks,
>>
>> Benjamin
>>
>>> Quoting Hannes Erven <ha...@erven.at>:
>>>
>>>
>>>
>>>> Hi Benjamin,
>>>>
>>>>
>>>> > * completionCoordinator is called and it returns no response
>>>> > (containing <Commit xsi:nil="true"
>>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>>>> > * participant is called and it returns no response
>>>> > * coordinator is called and it returns no response
>>>> > * completionInitiator is called and it returns no response
>>>>
>>>> That's OK, since those calls aren't expected to return anything. The
>>>> "Commit" message just tells the coordinator to commit. Once it has, it
>>>> sends a message to the completionInitiator containing the result -
>>>> Commited or Rolled Back.
>>>> (The same pattern applies to the calls between participant ("prepare")
>>>> and coordintor.)
>>>>
>>>>
>>> the reply to prepare can be either PREPARED or ABORTED. But both these
>>>
>> messages
>>
>>> are sent over seperate connections. you should be able to them however.
>>>
>>> --dasarath
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Yes you are absolutely right. Thanks; after exposing my application as
Web Service this is working now. But when I call my Web Service the
second time there is a exception at:
tm.begin();
The exception is:
AxisFault
faultCode: {http://schemas.xmlsoap.org/ws/2004/10/wscoor}InvalidState
faultSubcode:
faultString: The message was invalid for the current state of the activity.
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:The message was invalid for
the current state of the activity.
at
org.apache.kandula.coordinator.Coordinator.<clinit>(Coordinator.java:29)
at
org.apache.kandula.coordinator.CoordinatorImpl.registerOperation(CoordinatorImpl.java:63)
at
org.apache.kandula.coordinator.RegistrationImpl.registerOperation(RegistrationImpl.java:31)
This exception occurs when I invoke the second call of my TransactionWS
where I want to do exactly the same again. In this case there is no
message to the activcation coordinator but the first messages goes to
the registrationCoordinator which does not give any response.
My workflow is like this:
[BankOne] debit(1, 20)
[Bank] opening connection
[BankDBMS] isSameRM
[BankDBMS] start
[BankDBMS] debit
[BankDBMS] after debit amount = 480
[Bank] closing connection
[BankDBMS] end
true
[BankOne] credit(1, 20)
[Bank] opening connection
[BankDBMS] isSameRM
[BankDBMS] isSameRM
[BankDBMS] start
[BankDBMS] credit
[Bank] closing connection
[BankDBMS] end
true
[CallbackRegistry] registerCallback: timeout= 180000
[BankDBMS] end
[BankDBMS] end
[BankDBMS] prepare
[BankDBMS] prepare
[BankDBMS] commit
[BankDBMS] 480
[BankDBMS] commit
[BankDBMS] 520
[TransactionService] committed
Thanks,
Benjamin
> Quoting Benjamin Schmeling <Be...@gmx.de>:
>
>
>> Thank you very much for your support (Hannes and Dasarath)
>>
>> The example is really that what I needed and I got my Banking Service
>> working now. The only problem that remains is that the calling of the
>> commit() operation never returns. When I terminate my TestCase manually
>> and call it another time, there is a problem with the coordinator and
>> the transaction cannot be started again. How could I fix this?
>>
>
> I presume you are running your client as a standalone application-- correct?
> the commit/rollback operations wait for the COMMITTED/ABORTED messages from the
> coordinator. However, a standalone application cannot receive these messages.
> So the solution is to run your client inside a container like Tomcat where
> kandula has been deployed. That's what I've done in my example code. Whenever,
> we send an async message to which we expect a reply, kandula creates a dynamic
> endpoint-- axis2 does this automatically but for now we have to do it our
> selves on axis1.x.
>
> Earlier on we were able to run standalone apps without trouble b'cos we were
> using sync porttypes but now that we have switched to async, this is no longer
> possible. In fact, the reason you are able to even come this far is b'cos
> activation and registration still use sync porttypes!
>
> thanks,
> --dasarath
>
>
>
>> TransactionManagerImpl tm =
>> TransactionManagerImpl.getInstance();
>>
>> getBalance("1","DeutscheBankWS");
>> tm.begin();
>> sendDebit("20", "1","DeutscheBankWS");
>> sendCredit("20", "1","CommerzBankWS");
>> tm.commit(); <---
>>
>> Thanks,
>>
>> Benjamin
>>
>>> Quoting Hannes Erven <ha...@erven.at>:
>>>
>>>
>>>
>>>> Hi Benjamin,
>>>>
>>>>
>>>> > * completionCoordinator is called and it returns no response
>>>> > (containing <Commit xsi:nil="true"
>>>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>>>> > * participant is called and it returns no response
>>>> > * coordinator is called and it returns no response
>>>> > * completionInitiator is called and it returns no response
>>>>
>>>> That's OK, since those calls aren't expected to return anything. The
>>>> "Commit" message just tells the coordinator to commit. Once it has, it
>>>> sends a message to the completionInitiator containing the result -
>>>> Commited or Rolled Back.
>>>> (The same pattern applies to the calls between participant ("prepare")
>>>> and coordintor.)
>>>>
>>>>
>>> the reply to prepare can be either PREPARED or ABORTED. But both these
>>>
>> messages
>>
>>> are sent over seperate connections. you should be able to them however.
>>>
>>> --dasarath
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
> Thank you very much for your support (Hannes and Dasarath)
>
> The example is really that what I needed and I got my Banking Service
> working now. The only problem that remains is that the calling of the
> commit() operation never returns. When I terminate my TestCase manually
> and call it another time, there is a problem with the coordinator and
> the transaction cannot be started again. How could I fix this?
I presume you are running your client as a standalone application-- correct?
the commit/rollback operations wait for the COMMITTED/ABORTED messages from the
coordinator. However, a standalone application cannot receive these messages.
So the solution is to run your client inside a container like Tomcat where
kandula has been deployed. That's what I've done in my example code. Whenever,
we send an async message to which we expect a reply, kandula creates a dynamic
endpoint-- axis2 does this automatically but for now we have to do it our
selves on axis1.x.
Earlier on we were able to run standalone apps without trouble b'cos we were
using sync porttypes but now that we have switched to async, this is no longer
possible. In fact, the reason you are able to even come this far is b'cos
activation and registration still use sync porttypes!
thanks,
--dasarath
>
> TransactionManagerImpl tm =
> TransactionManagerImpl.getInstance();
>
> getBalance("1","DeutscheBankWS");
> tm.begin();
> sendDebit("20", "1","DeutscheBankWS");
> sendCredit("20", "1","CommerzBankWS");
> tm.commit(); <---
>
> Thanks,
>
> Benjamin
> > Quoting Hannes Erven <ha...@erven.at>:
> >
> >
> >> Hi Benjamin,
> >>
> >>
> >> > * completionCoordinator is called and it returns no response
> >> > (containing <Commit xsi:nil="true"
> >> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> >> > * participant is called and it returns no response
> >> > * coordinator is called and it returns no response
> >> > * completionInitiator is called and it returns no response
> >>
> >> That's OK, since those calls aren't expected to return anything. The
> >> "Commit" message just tells the coordinator to commit. Once it has, it
> >> sends a message to the completionInitiator containing the result -
> >> Commited or Rolled Back.
> >> (The same pattern applies to the calls between participant ("prepare")
> >> and coordintor.)
> >>
> >
> >
> > the reply to prepare can be either PREPARED or ABORTED. But both these
> messages
> > are sent over seperate connections. you should be able to them however.
> >
> > --dasarath
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
> Thank you very much for your support (Hannes and Dasarath)
>
> The example is really that what I needed and I got my Banking Service
> working now. The only problem that remains is that the calling of the
> commit() operation never returns. When I terminate my TestCase manually
> and call it another time, there is a problem with the coordinator and
> the transaction cannot be started again. How could I fix this?
I presume you are running your client as a standalone application-- correct?
the commit/rollback operations wait for the COMMITTED/ABORTED messages from the
coordinator. However, a standalone application cannot receive these messages.
So the solution is to run your client inside a container like Tomcat where
kandula has been deployed. That's what I've done in my example code. Whenever,
we send an async message to which we expect a reply, kandula creates a dynamic
endpoint-- axis2 does this automatically but for now we have to do it our
selves on axis1.x.
Earlier on we were able to run standalone apps without trouble b'cos we were
using sync porttypes but now that we have switched to async, this is no longer
possible. In fact, the reason you are able to even come this far is b'cos
activation and registration still use sync porttypes!
thanks,
--dasarath
>
> TransactionManagerImpl tm =
> TransactionManagerImpl.getInstance();
>
> getBalance("1","DeutscheBankWS");
> tm.begin();
> sendDebit("20", "1","DeutscheBankWS");
> sendCredit("20", "1","CommerzBankWS");
> tm.commit(); <---
>
> Thanks,
>
> Benjamin
> > Quoting Hannes Erven <ha...@erven.at>:
> >
> >
> >> Hi Benjamin,
> >>
> >>
> >> > * completionCoordinator is called and it returns no response
> >> > (containing <Commit xsi:nil="true"
> >> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> >> > * participant is called and it returns no response
> >> > * coordinator is called and it returns no response
> >> > * completionInitiator is called and it returns no response
> >>
> >> That's OK, since those calls aren't expected to return anything. The
> >> "Commit" message just tells the coordinator to commit. Once it has, it
> >> sends a message to the completionInitiator containing the result -
> >> Commited or Rolled Back.
> >> (The same pattern applies to the calls between participant ("prepare")
> >> and coordintor.)
> >>
> >
> >
> > the reply to prepare can be either PREPARED or ABORTED. But both these
> messages
> > are sent over seperate connections. you should be able to them however.
> >
> > --dasarath
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Thank you very much for your support (Hannes and Dasarath)
The example is really that what I needed and I got my Banking Service
working now. The only problem that remains is that the calling of the
commit() operation never returns. When I terminate my TestCase manually
and call it another time, there is a problem with the coordinator and
the transaction cannot be started again. How could I fix this?
TransactionManagerImpl tm =
TransactionManagerImpl.getInstance();
getBalance("1","DeutscheBankWS");
tm.begin();
sendDebit("20", "1","DeutscheBankWS");
sendCredit("20", "1","CommerzBankWS");
tm.commit(); <---
Thanks,
Benjamin
> Quoting Hannes Erven <ha...@erven.at>:
>
>
>> Hi Benjamin,
>>
>>
>> > * completionCoordinator is called and it returns no response
>> > (containing <Commit xsi:nil="true"
>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>> > * participant is called and it returns no response
>> > * coordinator is called and it returns no response
>> > * completionInitiator is called and it returns no response
>>
>> That's OK, since those calls aren't expected to return anything. The
>> "Commit" message just tells the coordinator to commit. Once it has, it
>> sends a message to the completionInitiator containing the result -
>> Commited or Rolled Back.
>> (The same pattern applies to the calls between participant ("prepare")
>> and coordintor.)
>>
>
>
> the reply to prepare can be either PREPARED or ABORTED. But both these messages
> are sent over seperate connections. you should be able to them however.
>
> --dasarath
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Thank you very much for your support (Hannes and Dasarath)
The example is really that what I needed and I got my Banking Service
working now. The only problem that remains is that the calling of the
commit() operation never returns. When I terminate my TestCase manually
and call it another time, there is a problem with the coordinator and
the transaction cannot be started again. How could I fix this?
TransactionManagerImpl tm =
TransactionManagerImpl.getInstance();
getBalance("1","DeutscheBankWS");
tm.begin();
sendDebit("20", "1","DeutscheBankWS");
sendCredit("20", "1","CommerzBankWS");
tm.commit(); <---
Thanks,
Benjamin
> Quoting Hannes Erven <ha...@erven.at>:
>
>
>> Hi Benjamin,
>>
>>
>> > * completionCoordinator is called and it returns no response
>> > (containing <Commit xsi:nil="true"
>> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
>> > * participant is called and it returns no response
>> > * coordinator is called and it returns no response
>> > * completionInitiator is called and it returns no response
>>
>> That's OK, since those calls aren't expected to return anything. The
>> "Commit" message just tells the coordinator to commit. Once it has, it
>> sends a message to the completionInitiator containing the result -
>> Commited or Rolled Back.
>> (The same pattern applies to the calls between participant ("prepare")
>> and coordintor.)
>>
>
>
> the reply to prepare can be either PREPARED or ABORTED. But both these messages
> are sent over seperate connections. you should be able to them however.
>
> --dasarath
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Hannes Erven <ha...@erven.at>:
> Hi Benjamin,
>
>
> > * completionCoordinator is called and it returns no response
> > (containing <Commit xsi:nil="true"
> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> > * participant is called and it returns no response
> > * coordinator is called and it returns no response
> > * completionInitiator is called and it returns no response
>
> That's OK, since those calls aren't expected to return anything. The
> "Commit" message just tells the coordinator to commit. Once it has, it
> sends a message to the completionInitiator containing the result -
> Commited or Rolled Back.
> (The same pattern applies to the calls between participant ("prepare")
> and coordintor.)
the reply to prepare can be either PREPARED or ABORTED. But both these messages
are sent over seperate connections. you should be able to them however.
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Hannes Erven <ha...@erven.at>:
> Hi Benjamin,
>
>
> > * completionCoordinator is called and it returns no response
> > (containing <Commit xsi:nil="true"
> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> > * participant is called and it returns no response
> > * coordinator is called and it returns no response
> > * completionInitiator is called and it returns no response
>
> That's OK, since those calls aren't expected to return anything. The
> "Commit" message just tells the coordinator to commit. Once it has, it
> sends a message to the completionInitiator containing the result -
> Commited or Rolled Back.
> (The same pattern applies to the calls between participant ("prepare")
> and coordintor.)
the reply to prepare can be either PREPARED or ABORTED. But both these messages
are sent over seperate connections. you should be able to them however.
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
> tm.getTransaction().enlistParticipant(false, new AbstractParticipant(){
>
> protected int prepare() throws XAException {
> System.out.println("prepare");
> return 0;
> }
> <soapenv:Body>
> <Prepare xsi:nil="true"
> xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>
> </soapenv:Body>
> </soapenv:Envelope>
>
> What is my mistake?
if the participant does not respond to the prepare msg by a prepared or an
aborted, the coordinator will retry 'prepare' a number of times. please try a
defined constant like Status.PREPARED etc. b'cos when you return 0, I'm not
sure to which of the defined constants it corresponds-- for example if 0 is
PREPARING the abstract participant simply waits without responding to the
coordinator!
since there was the need for a simpler example for a long time, I just coded a
quick banking service. Unfortunately I'm unable to commit the code to the svn
at the moment as svn.apache.org seems to be down. the code is available (for
now) at
http://www.cs.purdue.edu/homes/dweeratu/banking.zip
regards,
--dasarath
>
> Thanks,
>
> Benjamin
>
> > OK,
> >
> >
> >> the client does not stop automatically. 180secs after the commit was
> >> called, there is a timeout fault on the server.
> >
> > Can you please check if client-config.wsdd was deployed correctly also
> > on the server, and whether all messages contain WS-Addressing (To,
> > From, ...)-elements?
> >
> >
> >> Moreover I thought that the coordinator would call either prepare or
> >> commit of my service. This is not the case.
> >
> > The coordinator does call Prepare and later either Rollback or Commit
> > on your _participant_. The participant is a kandula component (its
> > more or less the transaction manager) that does many protocol specific
> > things for you.
> > One of them is that it automatically responds to the prepare message
> > after polling all locally enlisted transaction ressources, and if they
> > are prepared, your whole participant is.
> > When receiving a commit/rollback notification from the coordinator,
> > their decicision is likewise forwarded to all local resources.
> >
> > This was done for your convenience: just enlist all resources you used
> > in the global transaction, and they will automagically be committed or
> > rolled back -- your service shouldn't be doing something fundamentally
> > different, btw ;-)
> >
> > If you want explicit control over prepare/commit, you'll have to
> > enlist a custom ressource in the ongoing transaction (with the
> > transaction manager). If you do so, the TransactionManager will
> > automatically ask it for preparedness and later tell the transaction
> > result.
> > Some test cases in the Testsuite use this pattern to emulate resouce
> > errors, so you may look there to see some examples.
> >
> >
> > best regards,
> >
> > -hannes
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Quoting Benjamin Schmeling <Be...@gmx.de>:
> tm.getTransaction().enlistParticipant(false, new AbstractParticipant(){
>
> protected int prepare() throws XAException {
> System.out.println("prepare");
> return 0;
> }
> <soapenv:Body>
> <Prepare xsi:nil="true"
> xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>
> </soapenv:Body>
> </soapenv:Envelope>
>
> What is my mistake?
if the participant does not respond to the prepare msg by a prepared or an
aborted, the coordinator will retry 'prepare' a number of times. please try a
defined constant like Status.PREPARED etc. b'cos when you return 0, I'm not
sure to which of the defined constants it corresponds-- for example if 0 is
PREPARING the abstract participant simply waits without responding to the
coordinator!
since there was the need for a simpler example for a long time, I just coded a
quick banking service. Unfortunately I'm unable to commit the code to the svn
at the moment as svn.apache.org seems to be down. the code is available (for
now) at
http://www.cs.purdue.edu/homes/dweeratu/banking.zip
regards,
--dasarath
>
> Thanks,
>
> Benjamin
>
> > OK,
> >
> >
> >> the client does not stop automatically. 180secs after the commit was
> >> called, there is a timeout fault on the server.
> >
> > Can you please check if client-config.wsdd was deployed correctly also
> > on the server, and whether all messages contain WS-Addressing (To,
> > From, ...)-elements?
> >
> >
> >> Moreover I thought that the coordinator would call either prepare or
> >> commit of my service. This is not the case.
> >
> > The coordinator does call Prepare and later either Rollback or Commit
> > on your _participant_. The participant is a kandula component (its
> > more or less the transaction manager) that does many protocol specific
> > things for you.
> > One of them is that it automatically responds to the prepare message
> > after polling all locally enlisted transaction ressources, and if they
> > are prepared, your whole participant is.
> > When receiving a commit/rollback notification from the coordinator,
> > their decicision is likewise forwarded to all local resources.
> >
> > This was done for your convenience: just enlist all resources you used
> > in the global transaction, and they will automagically be committed or
> > rolled back -- your service shouldn't be doing something fundamentally
> > different, btw ;-)
> >
> > If you want explicit control over prepare/commit, you'll have to
> > enlist a custom ressource in the ongoing transaction (with the
> > transaction manager). If you do so, the TransactionManager will
> > automatically ask it for preparedness and later tell the transaction
> > result.
> > Some test cases in the Testsuite use this pattern to emulate resouce
> > errors, so you may look there to see some examples.
> >
> >
> > best regards,
> >
> > -hannes
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: kandula-dev-help@ws.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi,
I now enlisted a participant with:
tm.getTransaction().enlistParticipant(false, new AbstractParticipant(){
protected int prepare() throws XAException {
System.out.println("prepare");
return 0;
}
protected void commit() throws XAException {
System.out.println("commit");
}
protected void rollback() throws XAException {
System.out.println("rollback");
}
protected void forget() {
System.out.println("forget");
}
protected int getStatus() {
System.out.println("status");
return 0;
}
});
The communication stops at the participant now and the message sent to
the participant is repeated:
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<soapenv:Header>
<wsa:MessageID
soapenv:mustUnderstand="0">uuid:ea657a30-e052-11da-83bf-c28378dc7021</wsa:MessageID>
<wsa:To
soapenv:mustUnderstand="0">http://localhost:8080/axis/services/participant</wsa:To>
<wsa:Action
soapenv:mustUnderstand="0">http://schemas.xmlsoap.org/ws/2004/10/wsat/Prepare</wsa:Action>
<wsa:From soapenv:mustUnderstand="0">
<wsa:Address>http://localhost:8080/axis/services/coordinator</wsa:Address>
<wsa:ReferenceProperties>
<ns1:CallbackRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a2412790-e052-11da-83be-c28378dc7021</ns1:CallbackRef>
<ns1:ParticipantRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a25e2570-e052-11da-83be-c28378dc7021</ns1:ParticipantRef>
</wsa:ReferenceProperties>
</wsa:From>
<wsa:FaultTo soapenv:mustUnderstand="0">
<wsa:Address>http://localhost:8080/axis/services/faultDispatcher</wsa:Address>
<wsa:ReferenceProperties>
<ns1:CallbackRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a2412790-e052-11da-83be-c28378dc7021</ns1:CallbackRef>
<ns1:ParticipantRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a25e2570-e052-11da-83be-c28378dc7021</ns1:ParticipantRef>
</wsa:ReferenceProperties>
</wsa:FaultTo>
<ns2:CallbackRef soapenv:mustUnderstand="0"
xmlns:ns2="http://ws.apache.org/kandula">uuid:a2568450-e052-11da-8e76-c5b20989c32e</ns2:CallbackRef>
</soapenv:Header>
<soapenv:Body>
<Prepare xsi:nil="true"
xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>
</soapenv:Body>
</soapenv:Envelope>
What is my mistake?
Thanks,
Benjamin
> OK,
>
>
>> the client does not stop automatically. 180secs after the commit was
>> called, there is a timeout fault on the server.
>
> Can you please check if client-config.wsdd was deployed correctly also
> on the server, and whether all messages contain WS-Addressing (To,
> From, ...)-elements?
>
>
>> Moreover I thought that the coordinator would call either prepare or
>> commit of my service. This is not the case.
>
> The coordinator does call Prepare and later either Rollback or Commit
> on your _participant_. The participant is a kandula component (its
> more or less the transaction manager) that does many protocol specific
> things for you.
> One of them is that it automatically responds to the prepare message
> after polling all locally enlisted transaction ressources, and if they
> are prepared, your whole participant is.
> When receiving a commit/rollback notification from the coordinator,
> their decicision is likewise forwarded to all local resources.
>
> This was done for your convenience: just enlist all resources you used
> in the global transaction, and they will automagically be committed or
> rolled back -- your service shouldn't be doing something fundamentally
> different, btw ;-)
>
> If you want explicit control over prepare/commit, you'll have to
> enlist a custom ressource in the ongoing transaction (with the
> transaction manager). If you do so, the TransactionManager will
> automatically ask it for preparedness and later tell the transaction
> result.
> Some test cases in the Testsuite use this pattern to emulate resouce
> errors, so you may look there to see some examples.
>
>
> best regards,
>
> -hannes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
> OK,
>
>
>> the client does not stop automatically. 180secs after the commit was
>> called, there is a timeout fault on the server.
>
> Can you please check if client-config.wsdd was deployed correctly also
> on the server, and whether all messages contain WS-Addressing (To,
> From, ...)-elements?
>
All request messages contain WS-Addressing and I deployed the
client-config.wsdd to WEB-INF/classes.
>
>> Moreover I thought that the coordinator would call either prepare or
>> commit of my service. This is not the case.
>
> The coordinator does call Prepare and later either Rollback or Commit
> on your _participant_. The participant is a kandula component (its
> more or less the transaction manager) that does many protocol specific
> things for you.
> One of them is that it automatically responds to the prepare message
> after polling all locally enlisted transaction ressources, and if they
> are prepared, your whole participant is.
> When receiving a commit/rollback notification from the coordinator,
> their decicision is likewise forwarded to all local resources.
>
But how do I enlist the resources?
tm.getTransaction().enlistParticipant() would register a new
participant...but how could I use the existing one to get my resources
managed? At the moment the call of prepare and commit of the participant
of Kandula does not have any impact on my Banking WS.
> This was done for your convenience: just enlist all resources you used
> in the global transaction, and they will automagically be committed or
> rolled back -- your service shouldn't be doing something fundamentally
> different, btw ;-)
>
> If you want explicit control over prepare/commit, you'll have to
> enlist a custom ressource in the ongoing transaction (with the
> transaction manager). If you do so, the TransactionManager will
> automatically ask it for preparedness and later tell the transaction
> result.
> Some test cases in the Testsuite use this pattern to emulate resouce
> errors, so you may look there to see some examples.
>
>
> best regards,
>
> -hannes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi,
I now enlisted a participant with:
tm.getTransaction().enlistParticipant(false, new AbstractParticipant(){
protected int prepare() throws XAException {
System.out.println("prepare");
return 0;
}
protected void commit() throws XAException {
System.out.println("commit");
}
protected void rollback() throws XAException {
System.out.println("rollback");
}
protected void forget() {
System.out.println("forget");
}
protected int getStatus() {
System.out.println("status");
return 0;
}
});
The communication stops at the participant now and the message sent to
the participant is repeated:
<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<soapenv:Header>
<wsa:MessageID
soapenv:mustUnderstand="0">uuid:ea657a30-e052-11da-83bf-c28378dc7021</wsa:MessageID>
<wsa:To
soapenv:mustUnderstand="0">http://localhost:8080/axis/services/participant</wsa:To>
<wsa:Action
soapenv:mustUnderstand="0">http://schemas.xmlsoap.org/ws/2004/10/wsat/Prepare</wsa:Action>
<wsa:From soapenv:mustUnderstand="0">
<wsa:Address>http://localhost:8080/axis/services/coordinator</wsa:Address>
<wsa:ReferenceProperties>
<ns1:CallbackRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a2412790-e052-11da-83be-c28378dc7021</ns1:CallbackRef>
<ns1:ParticipantRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a25e2570-e052-11da-83be-c28378dc7021</ns1:ParticipantRef>
</wsa:ReferenceProperties>
</wsa:From>
<wsa:FaultTo soapenv:mustUnderstand="0">
<wsa:Address>http://localhost:8080/axis/services/faultDispatcher</wsa:Address>
<wsa:ReferenceProperties>
<ns1:CallbackRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a2412790-e052-11da-83be-c28378dc7021</ns1:CallbackRef>
<ns1:ParticipantRef
xmlns:ns1="http://ws.apache.org/kandula">uuid:a25e2570-e052-11da-83be-c28378dc7021</ns1:ParticipantRef>
</wsa:ReferenceProperties>
</wsa:FaultTo>
<ns2:CallbackRef soapenv:mustUnderstand="0"
xmlns:ns2="http://ws.apache.org/kandula">uuid:a2568450-e052-11da-8e76-c5b20989c32e</ns2:CallbackRef>
</soapenv:Header>
<soapenv:Body>
<Prepare xsi:nil="true"
xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>
</soapenv:Body>
</soapenv:Envelope>
What is my mistake?
Thanks,
Benjamin
> OK,
>
>
>> the client does not stop automatically. 180secs after the commit was
>> called, there is a timeout fault on the server.
>
> Can you please check if client-config.wsdd was deployed correctly also
> on the server, and whether all messages contain WS-Addressing (To,
> From, ...)-elements?
>
>
>> Moreover I thought that the coordinator would call either prepare or
>> commit of my service. This is not the case.
>
> The coordinator does call Prepare and later either Rollback or Commit
> on your _participant_. The participant is a kandula component (its
> more or less the transaction manager) that does many protocol specific
> things for you.
> One of them is that it automatically responds to the prepare message
> after polling all locally enlisted transaction ressources, and if they
> are prepared, your whole participant is.
> When receiving a commit/rollback notification from the coordinator,
> their decicision is likewise forwarded to all local resources.
>
> This was done for your convenience: just enlist all resources you used
> in the global transaction, and they will automagically be committed or
> rolled back -- your service shouldn't be doing something fundamentally
> different, btw ;-)
>
> If you want explicit control over prepare/commit, you'll have to
> enlist a custom ressource in the ongoing transaction (with the
> transaction manager). If you do so, the TransactionManager will
> automatically ask it for preparedness and later tell the transaction
> result.
> Some test cases in the Testsuite use this pattern to emulate resouce
> errors, so you may look there to see some examples.
>
>
> best regards,
>
> -hannes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
> OK,
>
>
>> the client does not stop automatically. 180secs after the commit was
>> called, there is a timeout fault on the server.
>
> Can you please check if client-config.wsdd was deployed correctly also
> on the server, and whether all messages contain WS-Addressing (To,
> From, ...)-elements?
>
All request messages contain WS-Addressing and I deployed the
client-config.wsdd to WEB-INF/classes.
>
>> Moreover I thought that the coordinator would call either prepare or
>> commit of my service. This is not the case.
>
> The coordinator does call Prepare and later either Rollback or Commit
> on your _participant_. The participant is a kandula component (its
> more or less the transaction manager) that does many protocol specific
> things for you.
> One of them is that it automatically responds to the prepare message
> after polling all locally enlisted transaction ressources, and if they
> are prepared, your whole participant is.
> When receiving a commit/rollback notification from the coordinator,
> their decicision is likewise forwarded to all local resources.
>
But how do I enlist the resources?
tm.getTransaction().enlistParticipant() would register a new
participant...but how could I use the existing one to get my resources
managed? At the moment the call of prepare and commit of the participant
of Kandula does not have any impact on my Banking WS.
> This was done for your convenience: just enlist all resources you used
> in the global transaction, and they will automagically be committed or
> rolled back -- your service shouldn't be doing something fundamentally
> different, btw ;-)
>
> If you want explicit control over prepare/commit, you'll have to
> enlist a custom ressource in the ongoing transaction (with the
> transaction manager). If you do so, the TransactionManager will
> automatically ask it for preparedness and later tell the transaction
> result.
> Some test cases in the Testsuite use this pattern to emulate resouce
> errors, so you may look there to see some examples.
>
>
> best regards,
>
> -hannes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Hannes Erven <ha...@erven.at>.
OK,
> the client does not stop automatically. 180secs after the commit was
> called, there is a timeout fault on the server.
Can you please check if client-config.wsdd was deployed correctly also
on the server, and whether all messages contain WS-Addressing (To, From,
...)-elements?
> Moreover I thought that
> the coordinator would call either prepare or commit of my service. This
> is not the case.
The coordinator does call Prepare and later either Rollback or Commit on
your _participant_. The participant is a kandula component (its more or
less the transaction manager) that does many protocol specific things
for you.
One of them is that it automatically responds to the prepare message
after polling all locally enlisted transaction ressources, and if they
are prepared, your whole participant is.
When receiving a commit/rollback notification from the coordinator,
their decicision is likewise forwarded to all local resources.
This was done for your convenience: just enlist all resources you used
in the global transaction, and they will automagically be committed or
rolled back -- your service shouldn't be doing something fundamentally
different, btw ;-)
If you want explicit control over prepare/commit, you'll have to enlist
a custom ressource in the ongoing transaction (with the transaction
manager). If you do so, the TransactionManager will automatically ask it
for preparedness and later tell the transaction result.
Some test cases in the Testsuite use this pattern to emulate resouce
errors, so you may look there to see some examples.
best regards,
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Hannes Erven <ha...@erven.at>.
OK,
> the client does not stop automatically. 180secs after the commit was
> called, there is a timeout fault on the server.
Can you please check if client-config.wsdd was deployed correctly also
on the server, and whether all messages contain WS-Addressing (To, From,
...)-elements?
> Moreover I thought that
> the coordinator would call either prepare or commit of my service. This
> is not the case.
The coordinator does call Prepare and later either Rollback or Commit on
your _participant_. The participant is a kandula component (its more or
less the transaction manager) that does many protocol specific things
for you.
One of them is that it automatically responds to the prepare message
after polling all locally enlisted transaction ressources, and if they
are prepared, your whole participant is.
When receiving a commit/rollback notification from the coordinator,
their decicision is likewise forwarded to all local resources.
This was done for your convenience: just enlist all resources you used
in the global transaction, and they will automagically be committed or
rolled back -- your service shouldn't be doing something fundamentally
different, btw ;-)
If you want explicit control over prepare/commit, you'll have to enlist
a custom ressource in the ongoing transaction (with the transaction
manager). If you do so, the TransactionManager will automatically ask it
for preparedness and later tell the transaction result.
Some test cases in the Testsuite use this pattern to emulate resouce
errors, so you may look there to see some examples.
best regards,
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi :-),
the client does not stop automatically. 180secs after the commit was
called, there is a timeout fault on the server. Moreover I thought that
the coordinator would call either prepare or commit of my service. This
is not the case. Maybe I misunderstood the WS-AtomicTransaction
protocol. I thinkt the debit operation of the Web Service should only do
the work without further propagation to the underlying database. When
the commit operation of my Web Service is called, the operation
propagates to the database. Is that right?
Thanks,
Benjamin
> Hi Benjamin,
>
>
> > * completionCoordinator is called and it returns no response
> > (containing <Commit xsi:nil="true"
> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> > * participant is called and it returns no response
> > * coordinator is called and it returns no response
> > * completionInitiator is called and it returns no response
>
> That's OK, since those calls aren't expected to return anything. The
> "Commit" message just tells the coordinator to commit. Once it has, it
> sends a message to the completionInitiator containing the result -
> Commited or Rolled Back.
> (The same pattern applies to the calls between participant ("prepare")
> and coordintor.)
>
> The message exchange itself looks OK - please be more verbose on what
> "fails" or what results you did not expect.
>
>
>
> Just some general remarks - I don't think they apply to your case,
> since the message exchange would fail earlier if something was not
> correctly set up:
>
> > I deployed all transactional services that are needed and put the
> > client-config.wsdd to the WEB-INF/classes of my Tomcat.
>
> Did you put the client-config.wsdd in both the classes directory of
> the Tomcat that runs Kandula, *and* into the classpath of your client
> program?
>
> If something went wrong there, the messages lack the ws-addressing
> fields that are necessary to correlate messages and transactions.
> Please look in your messages if they contain To, From, and the like
> fields.
>
> Another guess: did you set the correct kandula location in both
> kandula.properties files? (as above, there should be one in each
> runtime instance. Of course, you could - or have - deployed everything
> in one instance.)
>
>
> Liebe Grüße ;-)
>
> -hannes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Benjamin Schmeling <Be...@gmx.de>.
Hi :-),
the client does not stop automatically. 180secs after the commit was
called, there is a timeout fault on the server. Moreover I thought that
the coordinator would call either prepare or commit of my service. This
is not the case. Maybe I misunderstood the WS-AtomicTransaction
protocol. I thinkt the debit operation of the Web Service should only do
the work without further propagation to the underlying database. When
the commit operation of my Web Service is called, the operation
propagates to the database. Is that right?
Thanks,
Benjamin
> Hi Benjamin,
>
>
> > * completionCoordinator is called and it returns no response
> > (containing <Commit xsi:nil="true"
> > xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> > * participant is called and it returns no response
> > * coordinator is called and it returns no response
> > * completionInitiator is called and it returns no response
>
> That's OK, since those calls aren't expected to return anything. The
> "Commit" message just tells the coordinator to commit. Once it has, it
> sends a message to the completionInitiator containing the result -
> Commited or Rolled Back.
> (The same pattern applies to the calls between participant ("prepare")
> and coordintor.)
>
> The message exchange itself looks OK - please be more verbose on what
> "fails" or what results you did not expect.
>
>
>
> Just some general remarks - I don't think they apply to your case,
> since the message exchange would fail earlier if something was not
> correctly set up:
>
> > I deployed all transactional services that are needed and put the
> > client-config.wsdd to the WEB-INF/classes of my Tomcat.
>
> Did you put the client-config.wsdd in both the classes directory of
> the Tomcat that runs Kandula, *and* into the classpath of your client
> program?
>
> If something went wrong there, the messages lack the ws-addressing
> fields that are necessary to correlate messages and transactions.
> Please look in your messages if they contain To, From, and the like
> fields.
>
> Another guess: did you set the correct kandula location in both
> kandula.properties files? (as above, there should be one in each
> runtime instance. Of course, you could - or have - deployed everything
> in one instance.)
>
>
> Liebe Grüße ;-)
>
> -hannes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: kandula-dev-help@ws.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Hannes Erven <ha...@erven.at>.
Hi Benjamin,
> * completionCoordinator is called and it returns no response
> (containing <Commit xsi:nil="true"
> xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> * participant is called and it returns no response
> * coordinator is called and it returns no response
> * completionInitiator is called and it returns no response
That's OK, since those calls aren't expected to return anything. The
"Commit" message just tells the coordinator to commit. Once it has, it
sends a message to the completionInitiator containing the result -
Commited or Rolled Back.
(The same pattern applies to the calls between participant ("prepare")
and coordintor.)
The message exchange itself looks OK - please be more verbose on what
"fails" or what results you did not expect.
Just some general remarks - I don't think they apply to your case, since
the message exchange would fail earlier if something was not correctly
set up:
> I deployed all transactional services that are needed and put the
> client-config.wsdd to the WEB-INF/classes of my Tomcat.
Did you put the client-config.wsdd in both the classes directory of the
Tomcat that runs Kandula, *and* into the classpath of your client program?
If something went wrong there, the messages lack the ws-addressing
fields that are necessary to correlate messages and transactions. Please
look in your messages if they contain To, From, and the like fields.
Another guess: did you set the correct kandula location in both
kandula.properties files? (as above, there should be one in each runtime
instance. Of course, you could - or have - deployed everything in one
instance.)
Liebe Grüße ;-)
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: Writing a custom banking service
Posted by Hannes Erven <ha...@erven.at>.
Hi Benjamin,
> * completionCoordinator is called and it returns no response
> (containing <Commit xsi:nil="true"
> xmlns="http://schemas.xmlsoap.org/ws/2004/10/wsat"/>)
> * participant is called and it returns no response
> * coordinator is called and it returns no response
> * completionInitiator is called and it returns no response
That's OK, since those calls aren't expected to return anything. The
"Commit" message just tells the coordinator to commit. Once it has, it
sends a message to the completionInitiator containing the result -
Commited or Rolled Back.
(The same pattern applies to the calls between participant ("prepare")
and coordintor.)
The message exchange itself looks OK - please be more verbose on what
"fails" or what results you did not expect.
Just some general remarks - I don't think they apply to your case, since
the message exchange would fail earlier if something was not correctly
set up:
> I deployed all transactional services that are needed and put the
> client-config.wsdd to the WEB-INF/classes of my Tomcat.
Did you put the client-config.wsdd in both the classes directory of the
Tomcat that runs Kandula, *and* into the classpath of your client program?
If something went wrong there, the messages lack the ws-addressing
fields that are necessary to correlate messages and transactions. Please
look in your messages if they contain To, From, and the like fields.
Another guess: did you set the correct kandula location in both
kandula.properties files? (as above, there should be one in each runtime
instance. Of course, you could - or have - deployed everything in one
instance.)
Liebe Grüße ;-)
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org