I too agree. This way the business processing can be exposed outside the
context of JMS messaging.
A couple of suggestions.
Since MDBs are always stateless, I recommend only delegating to a stateless
SB.
I would cache the session bean lookup just as you have the DataSource lookup
at Bean creation.
I would also remove these object references in ejbRemove.
Cheers!
-----Original Message-----
From: Dhiren Mehta [mailto:dhirenm@(protected)]
Sent: Thursday, August 21, 2003 6:46 AM
To: J2EEPATTERNS-INTEREST@(protected)
Subject: Re: Design issue for MDB and JDBCs
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)
====================================================================
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)
