On Jan 23, 2008 12:22 PM, ant elder <[EMAIL PROTECTED]> wrote:
> On Jan 22, 2008 2:09 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> > snip...
> >
> > >
> > > 1) have the consumer spawn new threads to process each request (using
> > the
> > > existing Tuscany thread pool). One problem with that is i don't think
> we
> > > can't do QOS using the standard JMS APIs as once the consumer returns
> > the
> > > message is considered successfully processed but the spawned thread
> may
> > > still be processing or have an exception.
> > >
> >
> > Not sure I understand this para. If the consumer starts processing the
> > message shouldn't we consider that it has been successfully delivered.
> > Processing it may cause errors but these should be application errors
> that
> > in the @OneWay case presumably get written to a log or when the
> operation
> > is
> > not one way are put in a return message and sent back to the reply to
> > address.
> >
> > Simon
> >
>
>
> If the request message is part of a transaction when would we expect the
> transaction to be committed or rolled back - when the consumer starts the
> worker thread or after the service has been invoked on the worker thread?
>
> ...ant
>
> ...ant
>
It depends what you mean by transaction. From your note I'm guessing you are
looking at the case of an operation that is not @OneWay and where a managed
transaction context flows with the incomming message and it is expected that
the business operation runs within this transaction context
(propogatesTransaction?). Does that sound right?
As the transaction spans more than one component I expect you are looking at
the global transaction case. I wouldn't expect this to be committed or
rolled back until all of the service operations that are part of the
transaction have completed.
The issue you are up against is that the interaction with the component in
question has ceased to be strictly synchronous at the service end. I would
argue that, given the code as it is now, it is still synchronous at the
client end. I.e. the client will not continue executing until it receives a
response or error message via the replyTo address (Not sure what happens
with void return though - need to be careful in this case). In this respect
the SCA runtime where the transaction originated is still free to commit or
rollback the transaction based on the response from the original operation.
If the service that you are concerned with is not part of a global
transaction but has it's own local transaction then SCA can only commit or
roll back the local transaction once the message has completed ("after the
service has been invoked on the worker thread"). The client will still wait
until this has happened though so we ensure that the client will not fall
into the trap of trying to read uncommitted data.
Simon
