public @interface AsyncWebServiceQueue
The AsyncWebServiceQueue annotation describes the JMS queue that will be used to store the asynchronous requests for later processing. This annotation is applicable only to asynchronous web service implementation classes that are annotated with AsyncWebService annotation.
Transaction timeout in seconds for processing the message off the queue Meaningful only if the transaction is enabled or the method is non-idempotent This timeout is applied to the message driven bean that processes the request messages.
public abstract java.lang.String connectionFactory
The JNDI name of the QueueConnectionFactory
public abstract java.lang.String queue
The JNDI name of the JMS queue where asynchronous requests will be saved for later processing
public abstract boolean enableTransaction
If transaction is to be used for request-side MDB that processes messages from this queue.
public abstract int transactionTimeoutSeconds
Transaction timeout in seconds for processing the message off the queue Meaningful only if the transaction is enabled or the method is non-idempotent This timeout is applied to the message driven bean that processes the request messages. If specified 0 then the default value set at the server level is used.
public abstract int messageProcessorInitialPoolSize
The initial number of message processor instances in the pool to process the asynchronous requests.
public abstract int messageProcessorMaxPoolSize
The maximum number of message processor instances in the pool to process the asynchronous requests. Larger number will give you more throughput, but also may use more resources like threads and database connections etc.
public abstract java.lang.String messageProcessorPool
Name of the common message processor pool. If not specified, the service will use the default application level pool of message processors. If specified then a common named pool of message processors is used. While assembling an application, the first reference of a new common pool name creates a new pool of message processors in the application. After that any new service can refer to the same pool name and so can use the same message processor pool. One application having multiple asynchronous services may have more than one named pool of message processors. Asynchronous services sharing the same pool may interfere with each others performance under heavy load condition, so it is recommended that services having operations that take similar execution time should be grouped together. If there is a mix of fast and slow operations, then the fast operation may get queued up behind slow ones causing more delay to fast operations. A possible set of groups could be "slow", "medium" and "fast". The pool name does not signify any thing. This feature is useful to conserve resources like MDB, threads and database connections depending on the type of queue used.