 | 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 Eric Parker
Back
Some JMS implementations optimize communications within the same memory
space, provided you don't force them to write each message to a database by
declaring guaranteed message delivery. I've found that to be a key part of
building a JMS system that performs well. Skipping the call to JMS
entirely where possible definitely helps too.
I use POJOs rather than MDBs, but it doesn't seem like consuming or sending
the message should be much overhead compared to the actual transfer.
cheers,
-ep
At 12:20 PM 4/1/05 -0500, ashraf galal wrote:
>The overhead of JMS varies greatly depending on how it is used:
>acknowledgment modes, subscription durability etc. Guaranteed delivery
>(necessary for some operations) is likely to be slow.
>
>In some situations there may be simpler, lighter-weight alternatives to
>JMS, using thread creation (allowed outside the EJB container) or the
>Observer design pattern without JMS (that is, notifying listeners - who
>may perform actions in the calling thread or in a new thread - using an
>ordinary Java implementation, and not JMS).
>
>The Observer design pattern implemented this way will create much less
>overhead than JMS.
>
>However, whether it works in a clustered environment depends on what
>listeners must do.
>
>The server provides cluster-wide support for JMS.
>
>We can use this altenative approach to JMS:
>
>- When the application does not run in a cluster and is never likely to.
>
>- When it doesn't matter if all event processing occurs on the server on
>which the event was generated.
>
>
>
>
>
>
>
>Ashraf Galal
>(416)804-8359
> >From: Randy Dillon <rdillon@(protected)> >Reply-To: An interest list
> for Sun Java Center J2EE Pattern Catalog
> <J2EEPATTERNS-INTEREST@(protected)> >To:
> J2EEPATTERNS-INTEREST@(protected) >Subject: Re: MDB Performance >Date:
> Fri, 1 Apr 2005 07:12:59 -0600 > >>,,, > > > >>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). > > >You
> could try a JMS solution that doesn't use Message Beans. You'd >have
> to >handle the transactions yourself in that case, but still should
> be >able to >do connection pooling through the app server. > >>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.htm
> l >>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)
>====================================================================
>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)
Eric Parker
SAND Services Inc.
phone: 617.721.4350
http://www.sandservices.com
====================================================================
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)
<html>
Some JMS implementations optimize communications within the same
memory<br>
space, provided you don't force them to write each message to a database
by<br>
declaring guaranteed message delivery. I've found that to be a key
part of<br>
building a JMS system that performs well. Skipping the call to
JMS<br>
entirely where possible definitely helps too.<br><br>
I use POJOs rather than MDBs, but it doesn't seem like consuming or
sending<br>
the message should be much overhead compared to the actual
transfer.<br><br>
cheers,<br>
-ep<br><br>
<br>
At 12:20 PM 4/1/05 -0500, ashraf galal wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>The overhead of JMS
varies greatly depending on how it is used: acknowledgment modes,
subscription durability etc. Guaranteed delivery (necessary for some
operations) is likely to be slow. <br><br>
In some situations there may be simpler, lighter-weight alternatives to
JMS, using thread creation (allowed outside the EJB container) or the
Observer design pattern without JMS (that is, notifying listeners - who
may perform actions in the calling thread or in a new thread - using an
ordinary Java implementation, and not JMS). <br><br>
The Observer design pattern implemented this way will create much less
overhead than JMS. <br><br>
However, whether it works in a clustered environment depends on what
listeners must do. <br><br>
The server provides cluster-wide support for JMS.<br><br>
We can use this altenative approach to JMS:<br>
</font><font face="courier" size=2><br>
- </font><font face="Times New Roman, Times" size=2>When the application
does not run in a cluster and is never likely to.<br>
</font><font face="courier" size=2><br>
- </font><font face="Times New Roman, Times" size=2>When it doesn't
matter if all event processing occurs on the server on which the event
was generated.<br>
</font><br>
<br><br>
<br><br>
<br><br>
Ashraf Galal <br>
(416)804-8359<br>
>From: Randy Dillon <rdillon@(protected)> >Reply-To: An
interest list for Sun Java Center J2EE Pattern Catalog
<J2EEPATTERNS-INTEREST@(protected)> >To:
J2EEPATTERNS-INTEREST@(protected) >Subject: Re: MDB Performance
>Date: Fri, 1 Apr 2005 07:12:59 -0600 > >>,,, > > >
>>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). > > >You
could try a JMS solution that doesn't use Message Beans. You'd >have
to >handle the transactions yourself in that case, but still should be
>able to >do connection pooling through the app server. >
>>Any inputs would be much appreciated. >> >>Best
regards >>vp >>
>>====================================================================
>>Companion Site:
<a href="http://www.corej2eepatterns.com/" eudora="autourl">http://www
.corej2eepatterns.com</a>
>>J2EE BluePrints: <a href="http://java.sun.com/blueprints
/corej2eepatterns" eudora="autourl">http://java.sun.com/blueprints
/corej2eepatterns</a> >>List Archive: >><a href="http://archives
.java.sun.com/archives/j2eepatterns-interest.html" eudora="autourl">http:/
/archives.java.sun.com/archives/j2eepatterns-interest.html</a> >>
;Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to >>
;listserv@(protected) > >================================================
==================== >Companion Site: <a href="http://www.corej2eepatterns
.com/" eudora="autourl">http://www.corej2eepatterns.com</a> >J2EE BluePrints:
<a href="http://java.sun.com/blueprints/corej2eepatterns" eudora="autourl">http
://java.sun.com/blueprints/corej2eepatterns</a> >List Archive: ><a href=
"http://archives.java.sun.com/archives/j2eepatterns-interest.html" eudora=
"autourl">http://archives.java.sun.com/archives/j2eepatterns-interest.html</a>
>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to >
;listserv@(protected) <br>
==================================================================== Companion
Site: <a href="http://www.corej2eepatterns.com/" eudora="autourl">http://www
.corej2eepatterns.com</a> J2EE BluePrints: <a href="http://java.sun.com
/blueprints/corej2eepatterns" eudora="autourl">http://java.sun.com/blueprints
/corej2eepatterns</a> List Archive: <a href="http://archives.java.sun.com
/archives/j2eepatterns-interest.html" eudora="autourl">http://archives.java.sun
.com/archives/j2eepatterns-interest.html</a> Unsubscribing: email "signoff
J2EEPATTERNS-INTEREST" to listserv@(protected) </blockquote><br>
<br>
<br>
<div>Eric Parker</div>
<div>SAND Services Inc.</div>
<div>phone: 617.721.4350</div>
<div><a href="http://www.sandservices.com/" EUDORA=AUTOURL>http://www
.sandservices.com</a></div>
</html>
====================================================================
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)
|
|
|
