Client invokes the stateless session bean.The bean in turn have to access around 2000 rows of 10 different tables. Combine all the values sent it back to the client
I would like to know whether threading can be done using JMS
which will be called by a bean.For eg: I have to retrieve around 2000 rows each from 10 different tables and aggregate them and send it to the client.So instead of sequentially accessing each table, JMS program which
implements Runnable and spawns ten threads for acessing each table and aggregating the values(to be passed to the bean which will pass it to the client)
Does this violate the EJB specs or is an acceptable workaround?
Any suggestion will be helpful.
The session bean could send one JMS message per task you want to perform (one message per table). These tasks are executed in parallell and send the result to a common destination. The session bean blocks and waits for all messagess to be returned, aggregates the results and finally sends the result back to the client.
MessageDrivenBeans (EJB2.0) as listeners is a good match for this solution. You can also use a javax.jms.ServerSessionPool (I think it is optional in JMS) or standalone listener solution.
Suppose I have 10 Sql quires and I whant to
So in my session bean say Y I have to create 10 queues and pass
the each sql query to each queue as the message.
I have 10 startup class(which starts while weblogic server starts and listen for the message).This startup classes recieve the sql query and do the task(say.retrieving 2000 rows).These each startup class send vector object to each queue.(Another 10 queues not the previous 10 queues)
The session bean Y then waits and recieves the 10 object
(using threading).But threading is violating EJB spect..
In order to get the objects..How do i get that---------(1)
Any suggestion will be helpful
You need one Topic to for publishing messages and one Queue for receiving results. Queues and Topics are usually defined in your application server, you don't have to create them on the fly.
o Publish one message per query on the sendTopic from your session bean.
o After publishing all messages, the session bean blocks and wait for messages from the returnQueue. Synchronous read (block and wait) is provided by JMS (MessageConsumer.receive); you don't need threads or synchronization.
o On the receiver side, distribute the messages to different listeners to process the requests in parallell. Use MessageDrivenBeans, ServerSessionPool or a custom class for this purpose (I guess the custum class must depend on threads).
o Each listener performs the query and sends the result as a message on the returnQueue.
o As the result messages appear on the returnQueue, the session bean aggregates the results.
o When all messages are received, the session bean returns the final result to the client.
I guess I am more a beginner than the person asking the question, but I would love to see a code example of this particular effort. could anyone provide some?
I kept one Topic for publish message and one Queue
for result.(Using ServerSessionPool).[As you said]
Right now I have implemented as Java application for publishing the message.
(1)While recieving the message from the queue I couldn't get the message consistency.(I mean if i send 4 messages
sometimes i am getting 2 or 3 messages or no messages)
(2)suppose If i implement as session bean instead of Java application,then for every concurrent request output will be send to the Queue.How do I identify which output for which client
(3)Is there any methods available for cleaning the messages
in the queue.
1) Verify that all listeners are actually sending a reply message on the returnQueue. If an exception is thrown, no message will be sent.
2) Use a correlation ID. When publishing a message you get a message ID. This ID may be used as the correlation ID. The listener must set the original message ID as the correlation ID in the return message. Alternativley, use a message header field and a message filter for this purpose.
3) I think you have to use a QueueReceiver.receicveNoWait and read all messages from the Queue.
Ummm, I don't think a bean can block on a JMS queue (by the spec). If it could we would not need message-driven beans in EJB 2.0. I think the client needs to call the session bean to start the process, and then listen on a JMS queue to get the results.
A session bean can block and wait on a queue. However, a session bean can not be created and notified asynchronously when a message arrives; this is possible with MessageDrivenBeans, and the reason why we need them :)
See the thread "MessageDrivenBean Workaround?" for a way to get this effect (create and invoke a session bean on the async arrival of a JMS message) without EBJ 2.0 support.