 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Tomcat - JSP/Servlet container | | Struts - A MVC web framework | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | JSP - A mailing list about Java Server Pages specification and reference | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | |
Struts & Hibernate
|
|
|
| | | MDB Performance | MDB Performance 2005-04-01 - By vilayanur krishnan (DHL US)
Back
Hi,
I am in the process of architecting an enterprise application which, in a
nutshell, receives large volumes of messages (peak throughput of > 300 messages
200 bytes each per day) intermittently during the day from a series of sources
via MQ. These messages are transformed, written to a database. The latter
triggers the resultant transformations to be distributed to remote sites for
purposes of querying at the remote site. This propagation to the remote site is
planned using MQ based messaging with the message consumer being MDBs running
on an app server container (WAS 5.1) at the remote site.
This solution in its current form (this is currently deployed and functional)
is handling relatively smaller volumes as compared with the future requirements
and is built using a set of C daemons reading from a message queue using the MQ
Series client API. The daemons are the message consumers and are the equivalent
of the MDB with the exception that the current implementation manages its own
transactions. I am trying to rationalize the additional complexity that would
be introduced by bringing in a solution that leverages MDBs under WAS 5.1. My
questions are as follows:
1. Are MDBs truly scalable in a high transaction volume environment?
Scalability with MDBs is achieved on paper via clustering, controlling the pool
sizes of the MDBs, configuration settings such as max listener sessions etc...
How complex is the manageability aspect of realizing this architecture?
2. What is the overhead as far as performance goes introduced by the EJB
container within WebSphere?
3. Given that we have performance, reliability and availability as key NFRs
that need to be satisfied by the solution, should I rethink the architecture
vis-?-vis the use of MDBs under WebSphere/any other App Server? I have some
dated (2003) benchmarks run on the Windows 2000 environment from IBM that prove
that a non-MDB solution is less efficient. I'm not sure that I would go by this
, given that my current platform is Linux and WebSphere.
4. Are there any light-weight message consumers that could be leveraged instead
of MDBs that can mimic the functionality provided by MDBs (not so sure about
transaction management and connection pooling, though).
Any inputs would be much appreciated.
Best regards
vp
===================================================================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)
|
|
|
