Hi !
>1. Upon send the JMS implementation spawns a new thread which handles
>the JMS message, hence making the send asynchronous
>2. Upon send the JMS implementation gets a thread from a thread pool
>which handles the JMS message, hence making the send asynchronous
Well thats more of an implementation issue. I was referring to whether the framework
dictates a producer to 'send' messages synchronously or
asynchronously. I know for consumers and 'receive' the API has both
versions both synchronous 'receive' and asynchronous 'receive'.
> is more likely, as it is more efficient. However, if the pool is not
>large enough (i.e. it is empty at the point of sending a message) a new
>dispatcher thread will have to be created (i.e. case 1) by the JMS
>implementation thread pool. In order to be able to do this the JMS
>implementation must have the proper permissions (as outlined in earlier
>posts) and do appropriate doPrivileged calls (as outlined in earlier
>posts).
>
>Makes sense? Anything unclear?
Well I could talk about this all the time if you want :-). Is there a JMS mailing list
? I would like to get hold of a Open Source JMS implementation. However those guys at
Object Cubed seem to have disappeared.
Ashwin.
>
>/Rickard
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
