Java Mailing List Archive

http://www.junlu.com/

Home » Home (12/2007) » J2EE Pattern »

Re: MDB Performance

ashraf galal

2005-04-01

Replies:

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@AUSTIN.RR.COM> >Reply-To: An interest list for Sun Java Center J2EE Pattern Catalog <J2EEPATTERNS-INTEREST@JAVA.SUN.COM> >To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM >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.html >>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to >>listserv@java.sun.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@java.sun.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@java.sun.com From owner-j2eepatterns-interest@JAVA.SUN.COM Fri, 1 Apr 2005 14:56:08 Return-Path: Delivery-Date: Fri, 01 Apr 2005 15:06:34 -0500 Received: from swjscmail2.Sun.COM[192.18.99.108] (helo=swjscmail2.java.sun.com) by mx.perfora.net with ESMTP (Nemesis), id 0MKv22-1DHSPK0hR0-0002CY; Fri, 01 Apr 2005 15:06:18 -0500 Received: from swjscmail1 (swjscmail1.Sun.COM [192.18.99.107]) by swjscmail2.java.sun.com (Postfix) with ESMTP id DAA0821204; Fri, 1 Apr 2005 12:58:26 -0700 (MST) Received: from JAVA.SUN.COM by JAVA.SUN.COM (LISTSERV-TCP/IP release 1.8e) with spool id 60014081 for J2EEPATTERNS-INTEREST@JAVA.SUN.COM; Fri, 1 Apr 2005 12:52:42 -0700 X-Original-To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM Delivered-To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM Received: from web50303.mail.yahoo.com (web50303.mail.yahoo.com [206.190.38.57]) by swjscmail1.java.sun.com (Postfix) with SMTP id 0BEB44B50 for ; Fri, 1 Apr 2005 12:42:42 -0700 (MST) Received: (qmail 41892 invoked by uid 60001); 1 Apr 2005 19:56:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=Gvie2gxv45qyhoN+453FBCDgs0SoTu0fi4tkVUiRn2RRYEmyQFQjqcG3zIF52UwoltePqAiso+TRm6sjBMDtOjEfvTGEs9MWtK4/1wSAe7qTcN9SFypy/LbgnvZt+p94C8a1ywXZOG7O5Q/9jrt5tKAKFdWJElpMgWJ6tjOLXuQ= ; Received: from [165.115.60.154] by web50303.mail.yahoo.com via HTTP; Fri, 01 Apr 2005 11:56:08 PST MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-558752162-1112385368=:41204" Message-ID: <20050401195609.41890.qmail@web50303.mail.yahoo.com> Date: Fri, 1 Apr 2005 11:56:08 -0800 Reply-To: An interest list for Sun Java Center J2EE Pattern Catalog Sender: An interest list for Sun Java Center J2EE Pattern Catalog Comments: DomainKeys? See http://antispam.yahoo.com/domainkeys From: Patrick Blais Subject: Re: Is Singleton thread safe? To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM In-Reply-To: <1CF7DC6FDB2EFA45B523018955BC2C3556B2C3@pun001istex01.symphonysv.com> Precedence: list Envelope-To: java@JUNLU.COM X-SpamScore: 0.000 --0-558752162-1112385368=:41204 Content-Type: text/plain; charset=us-ascii It depends on the way you implement it. You might have thread safe issues if you have per say the following class: public class SequenceManager { private static SequenceManager manager; protected SequenceManager () { super(); } public static SequenceManager getInstance() { if(manager == null){ manager= new SequenceManager(); return manager; }else{ return manager; } is not thread safe. The following implementation is thread safe. THe difference is when the class loader will load the class, it will instanciate the variable manager and this, will be done only once. You do not need to synchronize the method... yoou need to prevent from loading the class twice. public class SequenceManager { private static SequenceManager manager=new SequenceManager(); protected SequenceManager () { super(); } public static SequenceManager getInstance() { return manager; } Sureshbabu Koya wrote: You cannot syncronize a static variable. It is always better if you modify your variables using set/get methods. Once you syncronize your set method your variable would be thread safe. I saw people using synchonize blocks for servlet instance variables instead of maintaining local variables. Since servlet is a singleton this is necessary. Apart from this case(Singleton) I did not see people trying to synchronize static variables. Regards, Suresh Koya -----Original Message----- From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Julia Liu Sent: Friday, April 01, 2005 9:47 PM To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM Subject: Re: Is Singleton thread safe? Thanks for reply. Could I Synchronized static varible? Sureshbabu Koya wrote: Making a singleton thread safe is up to you. You should also think about how the performance get a hit if you want to make a singleton threadsafe. regards, Suresh -----Original Message----- From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Julia Liu Sent: Friday, April 01, 2005 9:24 PM To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM Subject: Is Singleton thread safe? Hi, Is Singleton thread safe? Why? Thanks Julia Liu --------------------------------- Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. ==================================================================== 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@java.sun.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@java.sun.com Julia Liu --------------------------------- Yahoo! Messenger Show us what our next emoticon should look like. Join the fun. ==================================================================== 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@java.sun.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@java.sun.com --------------------------------- Do you Yahoo!? Make Yahoo! your home page ==================================================================== 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@java.sun.com --0-558752162-1112385368=:41204 Content-Type: text/html; charset=us-ascii
It depends on the way you implement it.
You might have thread safe issues if you have per say the following class:
public class SequenceManager {
private static SequenceManager manager;
protected SequenceManager () {
 super();
}
public static SequenceManager getInstance() {
if(manager == null){
 manager= new SequenceManager();
 return manager;
}else{
 return manager;
}
is not thread safe.
The following implementation is thread safe. THe difference is when the class loader will load the class,
it will instanciate the variable manager and this, will be done only once. You do not need
to synchronize the method... yoou need to prevent from loading the class twice.
public class SequenceManager {
private static SequenceManager manager=new SequenceManager();
protected SequenceManager () {
 super();
}
public static SequenceManager getInstance() {
 return manager;
}
 
Sureshbabu
Koya <Sureshbabu.Koya@SYMPHONYSV.COM> wrote:
You cannot syncronize a static variable. It is always better if you modify your variables using set/get methods. Once you syncronize your set method your variable would be thread safe.
 
I saw people using synchonize blocks for servlet instance variables instead of maintaining local variables. Since servlet is a singleton this is necessary. Apart from this case(Singleton) I did not see people trying to synchronize static variables.  
 
Regards,
Suresh Koya

 -----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Julia Liu
Sent: Friday, April 01, 2005 9:47 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Re: Is Singleton thread safe?

Thanks for reply.  Could I Synchronized static varible?

Sureshbabu Koya <Sureshbabu.Koya@SYMPHONYSV.COM> wrote:
Making a singleton thread safe is up to you. You should also think about how the performance get a hit if you want to make a singleton threadsafe.
 
regards,
Suresh
-----Original Message-----
From: An interest list for Sun Java Center J2EE Pattern Catalog [mailto:J2EEPATTERNS-INTEREST@JAVA.SUN.COM]On Behalf Of Julia Liu
Sent: Friday, April 01, 2005 9:24 PM
To: J2EEPATTERNS-INTEREST@JAVA.SUN.COM
Subject: Is Singleton thread safe?

Hi,
 
Is Singleton thread safe? Why?
 
Thanks



Julia  Liu 

Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun. ==================================================================== 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@java.sun.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@java.sun.com


Julia  Liu 

Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun. ==================================================================== 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@java.sun.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@java.sun.com

Do you Yahoo!?
Make Yahoo! your home page ==================================================================== 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@java.sun.com --0-558752162-1112385368=:41204--
©2008 junlu.com - Jax Systems, LLC, U.S.A.