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 Ruben DF <rd...@yahoo.es> on 2006/06/20 22:07:34 UTC
about RegistrationService
Hi,
I have some doubts about Kandula. Well, I have a
client with the following code:
wstm.begin();
serviceX.method();
wstm.commit();
Well, the serviceX is an Axis service. Firstable,
wstm.begin() obtains a transactional context, doesn't
obtain?. Afterwards, the client calls to method() from
serviceX. TxHandler notices that the message SOAP
contains a transactional context (ctx) and since it
has not a Transaction asociated, calls to
Mediator(tx,ctx) to register the context with the
participant. The code is:
protected void register(boolean durable,
CoordinationContext ctx)
throws RemoteException {
long timeout = 0;
Expires ex = ctx.getExpires();
if (ex != null)
timeout = ex.get_value().longValue();
epr =
CoordinationService.getInstance().getParticipantService(this,
timeout);
eprOfCoordinator = ctx.register(
durable ? ATCoordinator.PROTOCOL_ID_DURABLE_2PC
: ATCoordinator.PROTOCOL_ID_VOLATILE_2PC, epr);
}
My first question is...epr is referred to the client
or to the serviceX?.How does Kandula knows that my
participant is the service X and not the client? why
serviceX doesnt call to kandula's method Register() in
order that kandula registers serviceX as a
participant?
The second question is...what are the diferences
between register method from AbstractParticipant (see
code above) and register method from TransactionImpl?
Below is the code from TransactionImpl
private void register() throws RemoteException {
long timeout = 0;
Expires ex = ctx.getExpires();
if (ex != null)
timeout = ex.get_value().longValue();
callback = new CompletionInitiatorCallback();
EndpointReference epr =
CoordinationService.getInstance().getCompletionInitiatorService(
callback, timeout);
callback.setEndpointReference(epr);
eprOfCompletionCoordinator = ctx.register(
ATCoordinator.PROTOCOL_ID_COMPLETION, epr);
canInitiateCompletion = true;
}
the third question...if I comment the line
wstm.commit() of the client code...why dont I see the
message soap (in tcpmonitor) asociated to the
registrationService? (I only see the
activationCoordiantor)It is supposed that the
wstm.commit() doesn't generate the registration of the
ctx but the called to serviceX.method(), doesn't it?
Thanks in advance
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: about RegistrationService
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Hi Ruban,
> > the third question...if I comment the line
> > wstm.commit() of the client code...why dont I see the
> > message soap (in tcpmonitor) asociated to the
> > registrationService? (I only see the
> > activationCoordiantor)It is supposed that the
> > wstm.commit() doesn't generate the registration of the
> > ctx but the called to serviceX.method(), doesn't it?
>
> This is connected to the previous question. wstm.commit() registers for
> the CompletionProtocol, and I guess this is the call to the registration
> service you see in the tcpmonitor (and that disappears if you comment
> out that line).
>
> You are right that normally, before the initiator issues the
> commit/rollback command, ressources are registered. I suspect that your
> test service does not correctly do this, and you hence don't see more
> registration requests.
>
also,
when you comment out wstm.commit your client will not
register for completion protocol; it will also not commit
the transaction. A participant registers for completion
only if it needs to terminate a transaction. So registration
for Completion happens at the very end. The reason is
TransactionImpl is also used by participants who
use one of the 2PC protocols to interact with the coordinator-
such as your serviceX. If the registration happened up front
(when the TransactionImpl object is created),
it could be unnecessary.
thanks,
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: about RegistrationService
Posted by Dasarath Weeratunge <dw...@purdue.edu>.
Hi Ruban,
> > the third question...if I comment the line
> > wstm.commit() of the client code...why dont I see the
> > message soap (in tcpmonitor) asociated to the
> > registrationService? (I only see the
> > activationCoordiantor)It is supposed that the
> > wstm.commit() doesn't generate the registration of the
> > ctx but the called to serviceX.method(), doesn't it?
>
> This is connected to the previous question. wstm.commit() registers for
> the CompletionProtocol, and I guess this is the call to the registration
> service you see in the tcpmonitor (and that disappears if you comment
> out that line).
>
> You are right that normally, before the initiator issues the
> commit/rollback command, ressources are registered. I suspect that your
> test service does not correctly do this, and you hence don't see more
> registration requests.
>
also,
when you comment out wstm.commit your client will not
register for completion protocol; it will also not commit
the transaction. A participant registers for completion
only if it needs to terminate a transaction. So registration
for Completion happens at the very end. The reason is
TransactionImpl is also used by participants who
use one of the 2PC protocols to interact with the coordinator-
such as your serviceX. If the registration happened up front
(when the TransactionImpl object is created),
it could be unnecessary.
thanks,
--dasarath
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org
Re: about RegistrationService
Posted by Hannes Erven <ha...@erven.at>.
Hi Ruben,
> wstm.begin();
> serviceX.method();
> wstm.commit();
>
> Well, the serviceX is an Axis service. Firstable,
> wstm.begin() obtains a transactional context,
Yes, exactly.
> Afterwards, the client calls to method() from
> serviceX. TxHandler notices that the message SOAP
> contains a transactional context (ctx) and since it
> has not a Transaction asociated, calls to
> Mediator(tx,ctx) to register the context with the
> participant.
Yes.
> protected void register(boolean durable,
> CoordinationContext ctx)
> throws RemoteException {
> long timeout = 0;
> Expires ex = ctx.getExpires();
> if (ex != null)
> timeout = ex.get_value().longValue();
> epr =
> CoordinationService.getInstance().getParticipantService(this,
> timeout);
> eprOfCoordinator = ctx.register(
> durable ? ATCoordinator.PROTOCOL_ID_DURABLE_2PC
> : ATCoordinator.PROTOCOL_ID_VOLATILE_2PC, epr);
> }
>
> My first question is...epr is referred to the client
> or to the serviceX?.
It refers to the kandula endpoint at serviceX. The coordinator's
protocol epr is returned from the ctx.register() call.
> How does Kandula knows that my
> participant is the service X and not the client?
Sorry, I don't understand that question. What client?
> why serviceX doesnt call to kandula's method Register() in
> order that kandula registers serviceX as a
> participant?
It does, but you need to register an XAResource with the transaction
manager first.
If serviceX does not add resources to the transaction, there is no need
for the serviceX TransactionManager to register as a participant in the
WS-AT transaction.
> The second question is...what are the diferences
> between register method from AbstractParticipant (see
> code above) and register method from TransactionImpl?
> Below is the code from TransactionImpl
The difference is easily explained: the AbstractParticipant registers
for the 2PC protocol (which is used to coordinate the participants),
while TransactionImpl registers for the CompletionProtocol (which is
used by the initiator to issue the commit()/rollback() commands).
> the third question...if I comment the line
> wstm.commit() of the client code...why dont I see the
> message soap (in tcpmonitor) asociated to the
> registrationService? (I only see the
> activationCoordiantor)It is supposed that the
> wstm.commit() doesn't generate the registration of the
> ctx but the called to serviceX.method(), doesn't it?
This is connected to the previous question. wstm.commit() registers for
the CompletionProtocol, and I guess this is the call to the registration
service you see in the tcpmonitor (and that disappears if you comment
out that line).
You are right that normally, before the initiator issues the
commit/rollback command, ressources are registered. I suspect that your
test service does not correctly do this, and you hence don't see more
registration requests.
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: about RegistrationService
Posted by Hannes Erven <ha...@erven.at>.
Hi Ruben,
> wstm.begin();
> serviceX.method();
> wstm.commit();
>
> Well, the serviceX is an Axis service. Firstable,
> wstm.begin() obtains a transactional context,
Yes, exactly.
> Afterwards, the client calls to method() from
> serviceX. TxHandler notices that the message SOAP
> contains a transactional context (ctx) and since it
> has not a Transaction asociated, calls to
> Mediator(tx,ctx) to register the context with the
> participant.
Yes.
> protected void register(boolean durable,
> CoordinationContext ctx)
> throws RemoteException {
> long timeout = 0;
> Expires ex = ctx.getExpires();
> if (ex != null)
> timeout = ex.get_value().longValue();
> epr =
> CoordinationService.getInstance().getParticipantService(this,
> timeout);
> eprOfCoordinator = ctx.register(
> durable ? ATCoordinator.PROTOCOL_ID_DURABLE_2PC
> : ATCoordinator.PROTOCOL_ID_VOLATILE_2PC, epr);
> }
>
> My first question is...epr is referred to the client
> or to the serviceX?.
It refers to the kandula endpoint at serviceX. The coordinator's
protocol epr is returned from the ctx.register() call.
> How does Kandula knows that my
> participant is the service X and not the client?
Sorry, I don't understand that question. What client?
> why serviceX doesnt call to kandula's method Register() in
> order that kandula registers serviceX as a
> participant?
It does, but you need to register an XAResource with the transaction
manager first.
If serviceX does not add resources to the transaction, there is no need
for the serviceX TransactionManager to register as a participant in the
WS-AT transaction.
> The second question is...what are the diferences
> between register method from AbstractParticipant (see
> code above) and register method from TransactionImpl?
> Below is the code from TransactionImpl
The difference is easily explained: the AbstractParticipant registers
for the 2PC protocol (which is used to coordinate the participants),
while TransactionImpl registers for the CompletionProtocol (which is
used by the initiator to issue the commit()/rollback() commands).
> the third question...if I comment the line
> wstm.commit() of the client code...why dont I see the
> message soap (in tcpmonitor) asociated to the
> registrationService? (I only see the
> activationCoordiantor)It is supposed that the
> wstm.commit() doesn't generate the registration of the
> ctx but the called to serviceX.method(), doesn't it?
This is connected to the previous question. wstm.commit() registers for
the CompletionProtocol, and I guess this is the call to the registration
service you see in the tcpmonitor (and that disappears if you comment
out that line).
You are right that normally, before the initiator issues the
commit/rollback command, ressources are registered. I suspect that your
test service does not correctly do this, and you hence don't see more
registration requests.
best regards,
-hannes
---------------------------------------------------------------------
To unsubscribe, e-mail: kandula-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: kandula-dev-help@ws.apache.org