Hi,

We had to let go of an EJB Architecture using MDB/SLSB/EBs because we had a Thread.wait requirement in a particular use case, which couldn't be supported by the EJBs.

Any thoughts?

Thanks,
Avijeet

U may simulate "thread.wait()&thread.notify()" using JMS or MDB
like this in EJB:

doBusiness();
//block unti receive a message
Message notifyMessage = jmsReceiver.receive();
doOtherBusiness();

Per the specifications, you should not be doing something like that. Its not supported since that can cause problems, like what if the EJB is passivated.. you can extrapolate what all can happen I am sure.

Hope this helps.
Rakesh.

Ok, Let me try put a different question - if you have a requirement like processing messages in order, how wud you enforce it a MDB/EJB solution.

Regards,

I am not sure why this is so complicated.. I guess I am missing some of the background information. By default if you set up a reliable message queue, the messages are available in the order they were posted. As far as processing goes, if you want them to be processed sequentially only, then you don't need multiple threads. You can do all the processing in a single thread contineously.

Hope this helps.

Rakesh.

if you have a requirement like processing messages in order, how wud you enforce it a MDB/EJB solution.

I don't thin that you can rely on the message delivery as the specs doesn't make it mandatory that the messages will be delivered in right order. I am not sure about ejb 3.0 but ejb 2.0 specs doesn't required the message delivery in the right order.

Hope it helps.

By default, the delivery order is unspecified, and there is no requirement in the JMS spec that messages will be delivered in the order in which they are required, or in any particular order at all. The JMS provider can deliver the messages in any order it wants by default.

However, most JMS providers have a mechanism for specifying the order in which messages are to be delivered. WebLogic, for example, uses Destination Keys to specify the order in which messages are to be delivered.

So using WebLogic you could achieve what you want by deploying one instance of the MDB only and then specifying that messages are to be delivered in order of JMSTimestamp (assuming that either there is a single source for the messages or that there are multiple sources which can be relied on to have co-ordinated timestamps).

Also keep in mind that even with a single mdb that in high volume scenarios messages may be processed by multiple ejb instances concurently... furthur obscuring sequencing.

Is it possible to bundle the entire sequense of requests in a single message? (assuming the size of the bundle is not prohibitive).

The scenario is like this - 1) Add 2) update, but if the update message comes first then, it has to wait. And bundleing Add, update in one message is a good idea, but It can't be applied across multiple coarse-grained transactions.

-thanks

Multiple threads help in achieving scalability, and all the messages are not required to be processed sequentially, but only those messages which are related to some entity. I am not very sure if we can ensure any ordering in queues, like other said its not given.

thanks-