Author |
Message
|
fjb_saper |
Posted: Fri Sep 09, 2005 6:28 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
What is your meaning of cloning ? |
|
Back to top |
|
 |
newtomq22 |
Posted: Thu Sep 15, 2005 7:43 am Post subject: |
|
|
Novice
Joined: 08 Apr 2005 Posts: 24
|
This is what i got from the sun tutorial
Code: |
Like a stateless session bean, a message-driven bean can have many interchangeable instances running at the same time. The container can pool these instances to allow streams of messages to be processed concurrently. The container attempts to deliver messages in chronological order when it does not impair the concurrency of message processing, but no guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class. Because concurrency can affect the order in which messages are delivered, you should write your applications to handle messages that arrive out of sequence.
|
Doesn't this mean that running MDBs on one instance also won't guarantee sequencing?
Please advice... |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Sep 15, 2005 6:46 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
newtomq22 wrote: |
This is what i got from the sun tutorial
Code: |
Like a stateless session bean, a message-driven bean can have many interchangeable instances running at the same time. The container can pool these instances to allow streams of messages to be processed concurrently. The container attempts to deliver messages in chronological order when it does not impair the concurrency of message processing, but no guarantees are made as to the exact order in which messages are delivered to the instances of the message-driven bean class. Because concurrency can affect the order in which messages are delivered, you should write your applications to handle messages that arrive out of sequence.
|
Doesn't this mean that running MDBs on one instance also won't guarantee sequencing?
Please advice... |
You are quite right. What you need however to do is to deploy your MDB only to one instance of WAS and on that instance only run one instance of the MDB(this is configurable). We run anything from 1 to 10 instances of the MDB on the same queue. The configuration of the max number of instances to run for the same MDB / same Queue is configurable in the deployment descriptor.
Enjoy  |
|
Back to top |
|
 |
newtomq22 |
Posted: Mon Sep 26, 2005 6:17 am Post subject: |
|
|
Novice
Joined: 08 Apr 2005 Posts: 24
|
Firstly thanks for the prompt reply...sorry..should have done more research on MDBs....
yeah..read some more articles about MDBs over the weekend...it cleared a lot of stuff but posed some new questions too...
one of the articles i read was mr. parkinson's
Get the most out of high performance message-driven beans and WebSphere Application Server
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0508_parkinson/0508_parkinson.html
There he says the following
Code: |
In many high performance scenarios, message order is not important since, in these cases, we can configure WebSphere Application Server to process many messages concurrently. This is an especially important technique on multi-processor systems, where concurrency can (in principle) be used without degrading response time.
|
Does this mean that performance is affected using MDBs where you cannot employ concurrency?
Secondly, the normal practice is to call a stateless session bean from your MDB which does all the business processing. In my case, all the processing logic is in the web module so are there any drawbacks in calling the web module code from the MDB
or the only route is MDB --> session bean?
Thanks for all your responses.. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Sep 26, 2005 7:17 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Quote: |
Does this mean that performance is affected using MDBs where you cannot employ concurrency? |
Obviously. If you have to process serially you can only run one instance.
Processing you can run x instances of the MDB at the same time...
Let x be 20 and you process up to 20 times faster....
Quote: |
Secondly, the normal practice is to call a stateless session bean from your MDB which does all the business processing. In my case, all the processing logic is in the web module so are there any drawbacks in calling the web module code from the MDB
or the only route is MDB --> session bean? |
Well this really depends as to where the bean is called from and how your implementation is architected. Normally when using an MDB you do asynchronous processing of the queue content and you should not have any human interaction. As such MDB to Stateless bean is the accepted pattern.
Going to a request response pattern you would use a receiver as a consumer and not an MDB.
Enjoy  |
|
Back to top |
|
 |
newtomq22 |
Posted: Wed Oct 05, 2005 11:01 am Post subject: |
|
|
Novice
Joined: 08 Apr 2005 Posts: 24
|
There is no human interaction involved in our case. We
receive the message, --> process it (insert/update data) --> if no exceptions thrown, the msg is logged into a msg recevd log and if there some exceptions then the msg is logged into the msg rejected log ( we don't try to requeue it or anything). The logs are just flat files.
When u say request-response pattern, are u referring to the case where someone has to send a msg back acknowledging that the msg was received?
Thanks a lot for all your responses.
Tarun |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Oct 05, 2005 12:32 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
newtomq22 wrote: |
There is no human interaction involved in our case. We
receive the message, --> process it (insert/update data) --> if no exceptions thrown, the msg is logged into a msg recevd log and if there some exceptions then the msg is logged into the msg rejected log ( we don't try to requeue it or anything). The logs are just flat files.
When u say request-response pattern, are u referring to the case where someone has to send a msg back acknowledging that the msg was received?
Thanks a lot for all your responses.
Tarun |
The someone in the request / response model can be a process or an MDB. It need not have any human intervention...
Sound design. I hope that when you say logging to files you really mean passing to a Logger that writes it to files...
If not you do not really allow for multi threading and concurrent processing of the MDB...
Usually that kind of logging is being hosted by the DB. At the end of each day you can then move info from the DB tables to a file and delete it.
Enjoy  |
|
Back to top |
|
 |
newtomq22 |
Posted: Thu Oct 06, 2005 6:42 am Post subject: |
|
|
Novice
Joined: 08 Apr 2005 Posts: 24
|
yeah..we are using log4j for all the logging...we don't use db..we log directly to the flat files and they are archived every 12 hrs...
so in my case, there shouldn't be a problem if i go the MDB --> Web Module path or MDB calls the session bean and session bean calls the class which is part of the web module. i saw a lot of articles suggesting MDB to the session bean but couldn't find anything on the disadvantages/things to take care of
if we don't call session bean from a MDB.
Probably this falls more under general J2EE details but i felt that with MDBs lot of things apply differently
Do you know of any docs where there is xplained in more detail?
Thank You. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 06, 2005 12:44 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Read up on the JMS spec from the J2EE set (search sun website).
IBM has a few interesting redbooks about Websphere and MQ.
Check out as well the JMS Topography redbook and it's bilbiography.
Enjoy  |
|
Back to top |
|
 |
|