 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | 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 | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Design issue for MDB and JDBCs | Design issue for MDB and JDBCs 2003-08-21 - By Dhiren Mehta
Back
I agree with Igor that from design modularity and extensibility point of view
MDB should only be treated as message handler rather than message processor.
For processing the requests, session bean should be used. This also gives you
the flexibility of offering the same service synchronous processing, apart from
async. nature of the messaging.
-- --Original Message-- --
From: Igor Cunko [mailto:icunko@(protected)]
Sent: Thursday, August 21, 2003 5:06 PM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Design issue for MDB and JDBCs
> -- --Original Message-- --
> From: Ivy Se [mailto:ivy12see@(protected)]
> Subject: Design issue for MDB and JDBCs
>
> I've got a design issue.
>
> Should I make JDBC calls on the MDBs or 'outsourced'
> it to a Stateless Session Beans?
>
> You see, the code has
>
> public void ejbCreate() throws CreateException {
> try {
> InitialContext ic = new InitialContext();
>
> dataSource = (DataSource)
> ic.lookup(JNDI_DATASOURCE);
>
> ic.close();
>
> And the onMessage has got JDBC calls and closing the
> connection once done, etc.
>
>
> QUESTION: Is it going to be inefficient to have such
> JDBC stuff for a MDBs that listens to hundreds of
> messages from a given Queue?
>
> What's your recommendation....to have them passed on
> to a pool of stateless beans to handle to JDBCs?
>
> Thank you.
For lookups, you can cache result first time you got reference so you can
avoid creating new context each time. I don't see any difference in
performance executing code in MDB or session bean, although I would delegate
to session bean because it gives you flexibility to aggregate functionality
easier than with MDB.
Igor
===================================================================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)
MASTEK
"Making a valuable difference"
Mastek in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opinions expressed in this e-mail are those of the individual and not that of
Mastek Limited, unless specifically indicated to that effect. Mastek Limited
does not accept any responsibility or liability for it. This e-mail and
attachments (if any) transmitted with it are confidential and/or privileged and
solely for the use of the intended person or entity to which it is addressed.
Any review, re-transmission, dissemination or other use of or taking of any
action in reliance upon this information by persons or entities other than the
intended recipient is prohibited. This e-mail and its attachments have been
scanned for the presence of computer viruses. It is the responsibility of the
recipient to run the virus check on e-mails and attachments before opening them
. If you have received this e-mail in error, kindly delete this e-mail from all
computers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
===================================================================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)
|
|
|
