- Re: Regarding restricting number of instant for MDB - Found word(s) 2004-07-19 - By Stefan Frank
Back
I'd really like to hear, wether somebody is currently using MDB for this
kind of "task-farming": We tried this in a similar project and ended up
with all sorts of dead-lock-problems: Make sure, that you *really*
understand the transactional behaviour of your MDB's: In a clustered
environment where Messages are triggered that in turn trigger MDB that
trigger other MDB's that start transactions on your SessionBeans that
concurrently access ressources on your DB - you end up with a very
complex net of concurrent transactions. Make sure, that you now how your
MDB's behave and how the workflow runs and which ressources your Job-Net
will concurrently access... (In the end, we dumped the MDB-approach and
are now using a pure, offline, batch like processing, with mainly the
Database alone coordinating Transactions& managing the concurrency
manually (delegating this taks away to a container is not always a good
idea)
If you still want to venture down this path, here are some remarks on
your questions:
Kamaraj, Pushparaj wrote:
> Hi,
> Thank you very much Binidas.
>
> If I explain the scenario it will be better for understanding.
>
> We have a program, which will do some complex calculation, which
> needs to be triggered asynchronously from screen, and the process may take
> 15 mins to complete. The screen will not wait until the calculation is
> complete. This is the reason we preferred JMS and MDB. The screen event will
> put the message into the queue and JMS will hand over the message to MDB for
> processing.
>
> Is it a correct approach?
Apart from my not-so-good-experience (see above) this should be a
feasible approach...
>
> Assume the Object pool size is 5 and there are 6 concurrent users
> are doing the operation which will end up in 6 messages. As the Object pool
> size is 5, all the pool instant will be used, for 6th message, as there is
> no object is free in the pool the system will instantiated a new one. The
> same way if there are 25 concurrent messages there is a possibility 25
> instant may be running.
>
> Is my understanding correct?
no, this actually depends on the way you set up your MDB-Pool: If you
give it an upper limit (which you should), the Container only
instantiates MDB's up to this limit. Messages, that cannot be processed
immediately, are queued. Almost every Container supports some kind of
Message-Persistence (either by storing undelivered Messages in the
filesystem or in a database) - so these messages are not even lost when
the server crashes. When an MDB has done it's processing, it is returned
back into the pool and can then be delivered another message.
>
> The requirement is if the pool size is 5 and already all the objects
> in the pool is under use then the 6th message needs to wait in the queue
> until one object is returned to the pool. For that what configuration needs
> to be done?.
check your max-beans-in-free-pool and this should be it, this is
standard-behaviour of ervery container...
>
> Kind regards,
> K.Pushparaj.
>
>
>
>
>>-- --Original Message-- --
>>From: Binildas C. A. [SMTP:binil_christudas@(protected)]
>>Sent: Monday, July 19, 2004 12:33 PM
>>To: J2EEPATTERNS-INTEREST@(protected)
>>Subject: [SPAM] - Re: Regarding restricting number of instant for MDB
>>- Found word(s) list error in the Text body.
>>
>>Hi
>>
>>Instead of "If the system start associating a MDB for each message ", The
>>system will associate some instance of the MDB which is already available
>>in
>>the pool for each message. This means, for each individual message, we
>>dont
>>end up with each seperate MDB instance. Instead, MDB instances get reused
>>(Object pooling). This is the very use of using MDB than a standalone JMS
>>listener(of course, with other features like TX, etc...)
>>
>>Instead of "for each message then there will be many processes running in
>>parallel" , we can re-write as follows:
>>For each message, container wont start seperate process, and not even a
>>seperate thread. Instead, container will chose a thread from the thread
>>pool, and associate that thread to the chosed MDB context, and the message
>>will be served by this MDB.
>>
>>Now, to tune the number of MDBs and all - This a task which we need to do
>>taking into consideration things like:
>>
>>1. App Server
>>2. Size of application
>>3. Other applications in server
>>4. Frequency of messages
>>5. Time to serve each message
>>6...
>>The list goes like this...
>>
>>Binildas
>>Sr. Tech. Architect
>>http://www.infosys.com/setlabs/)
>>
>>-- -- Original Message -- --
>>From: "Kamaraj, Pushparaj" <Pushparaj_Kamaraj@(protected)>
>>To: <J2EEPATTERNS-INTEREST@(protected)>
>>Sent: Monday, July 19, 2004 12:33 PM
>>Subject: Regarding restricting number of instant for MDB
>>
>>
>>
>>>Hi,
>>> We are having Message driven bean and other session beans in the
>>>same container.
>>> The characteristics of MDB is whenever a message is added to the
>>
>>JMS
>>
>>>queue it will be instantiated to serve the message.
>>> We are expecting there will be large number of messages coming
>>
>>to
>>
>>>JMS queue. If the system start associating a MDB for each message then
>>
>>there
>>
>>>will be many processes running in parallel, which will reduce the system
>>>performance. How to restrict the maximum number of active MDB in the
>>
>>system?
>>
>>>And the configuration should not affect other session bean instants. If
>>
>>we
>>
>>>restrict the maximum instant to 10, at the most there will be only 10
>>
>>MDBs
>>
>>>and other request will be waiting in the JMS queue.
>>>
>>> We are using the following configuration to achieve the above
>>>requirement. Is that correct?
>>>
>>><message-driven-descriptor>
>>> <pool>
>>>
>>><max-beans-in-free-pool>6</max-beans-in-free-pool>
>>>
>>><initial-beans-in-free-pool>3</initial-beans-in-free-pool>
>>> </pool>
>>> </message-driven-descriptor>
>>>
>>>Thanks,
>>>K.Pushparaj.
>>>
>>>__ ____ ____ ____ ____ ____ ____ ____ ______
>>>Confidential: This electronic message and all contents contain
>>
>>information
>>
>>>from Syntel, Inc. which may be privileged, confidential or otherwise
>>>protected from disclosure. The information is intended to be for the
>>>addressee only. If you are not the addressee, any disclosure, copy,
>>>distribution or use of the contents of this message is prohibited. If
>>
>>you
>>
>>>have received this electronic message in error, please notify the sender
>>>immediately and destroy the original message and all copies.
>>>
>>>====================================================================
>>>Companion Site: http://www.corej2eepatterns.com
>>>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>>>List Archive:
>>
>>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>>
>>>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>>
>>listserv@(protected)
>>
>>====================================================================
>>Companion Site: http://www.corej2eepatterns.com
>>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>>List Archive:
>>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>>listserv@(protected)
>>
>
> __ ____ ____ ____ ____ ____ ____ ____ ______
> Confidential: This electronic message and all contents contain information
> from Syntel, Inc. which may be privileged, confidential or otherwise
> protected from disclosure. The information is intended to be for the
> addressee only. If you are not the addressee, any disclosure, copy,
> distribution or use of the contents of this message is prohibited. If you
> have received this electronic message in error, please notify the sender
> immediately and destroy the original message and all copies.
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com
> J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
> List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
