Re: JMS services and threading
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. Following up after more thinking: After, and that means that spawning threads will not work with transactions. Don't most JMS users want transactions as well? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMS services and threading
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
Re: JMS services and threading
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
Re: JMS services and threading
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JMS services and threading
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 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. Note though that we don't currently support QOS option with the JMS binding. 2) In a J2EE environment we could use an MDB. That gets more complicated to implement and may require some manual configuration 3) Use a JCA adapter. I don't know so much about implementing this but i believe that would enable control of both the threading and QOS aspects. Of those (1) seems like the easiest to do right now to get concurrent requests on JMS services working but one of the other approaches is probably needed in the long term. Anyone have any comments on this or other approaches to suggest? ...ant
Re: JMS services and threading
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
