Jean-Sebastien Delfino wrote:
ant elder wrote:
[snip]
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
After.
ant elder wrote:
[snip]
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
After.
--
Jean-Sebastien
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
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 consu
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 spawne
Right now JMS services use a single JMS consumer per service so requests are
single threaded. We could do nothing and just live with this restriction or
we could improve this by doing things such as:
1) have the consumer spawn new threads to process each request (using the
existing Tuscany thread
