Quoting Benjamin Schmeling <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
