• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why would the container create more instances of the same MDB  RSS feed

 
Balamaci Serban
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well the answer would imediately be because of the concurent processing. But if there are more messages and I need to process them in order. I mean what if i have only two instances of the same MDB. They both consume 2 diferent messages. I guess the get phase must be syncronised or we'd be in trouble of getting the same message for the 2 beans. But if the bean1 starts processing mesage1 and bean2 starts procesing message2 and for some reason message2 gets finished first and writtes say in a database, then the order of the messages is messed up, right?
Well what about MDB with CMT. Does the fact that the session is transacted does block the other beans from processing till the current MDB returns from it's onMesssage()? If so why would we need multiple instances?
[ May 26, 2005: Message edited by: Balamaci Serban ]
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All the spec. says about concurrency in MDBs is that no guarentees are made to the order in which messages are delivered. Your MDBs should therefore always be written in a way that they can handle out of sequence messages. If this is true, then when two instances of the same MDB processing two messages it doesn't matter which is persisted first.

Including a message in one transaction is a bad idea. Since MDBs are asynchronous you've no guarentees when a message will be consummed. So in theory it could be hours, not seconds till your transaction finishes. Doing this defeats the purpose of using an asynchronous component.
[ May 26, 2005: Message edited by: Paul Sturrock ]
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
MDBs are like stateless session beans and entity beans: they are pooled for performance reasons. Normally, you would want the container to create as many instances as necessary to process the requests.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Am I correct that when you configure the number of beans in the pool this also controls the number of threads that will process the inbound messages? In the future I expect to provide an API to other systems via MQ-Series. The partners may be 24x7 web sites, while we only guarantee normal working hours. If our system is down MQ will persist the messages until we come up. When we come up, I don't want a zillion stored messages to flood my system, so I'll set the number of MDBs that accept the inbound messages fairly low. Does that make sense?
 
Balamaci Serban
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Sturrock:
All the spec. says about concurrency in MDBs is that no guarentees are made to the order in which messages are delivered.

Well yes, but most of the JMS servers say that they deliver in order.

But if i were to rely on that, i still would have to specify only one instance of the bean, right? In order to maintain the order of the processing.
Originally posted by Paul Sturrock:

Including a message in one transaction is a bad idea. Since MDBs are asynchronous you've no guarentees when a message will be consummed.


Well i'm not quite clear on the transaction concept yet in JMS, but i was thinking more like in the http://www.javaworld.com/javaworld/jw-03-2002/jw-0315-jms_p.html way. In a CMT MDB I thought that the transaction starts when the message has arrived as a parameter in the onMessage() method of the bean, and it spans till the method returns so that would not take so much time. Does that involve some kind of lock as with database transactions that would make the MDB work in serial order, rather than concurent?
[ May 26, 2005: Message edited by: Balamaci Serban ]
 
Balamaci Serban
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
Am I correct that when you configure the number of beans in the pool this also controls the number of threads that will process the inbound messages?

Well from what i know the ideea of EJB is to have multiple threads of single threaded bean instances. So less instances, less threads i guess.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Well yes, but most of the JMS servers say that they deliver in order.

True. But you don't have a cast iron guarentee, and relying on the features of a particular JMS server limit the portability of your application.

I understand your transation query now. I took CMT to mean wrapping the delivery of a message to an MDB in a transaction (which is bad for the reasons I mention above), not wrapping the processing of the message in a transaction which is common enough. It doesn't solve your problem though, since the order the messages is still not guarenteed, or should more than one instance of the bean be processing a message you still don't know which will get there first.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!