RES: Design issue for MDB and JDBCs

Google

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

Subjects

•	JSP editor plugin for eclipse ?
•	org apache jasper JasperException: Unable to compile class for JSP
•	Tomcat: Connection reset by peer: socket write error
•	Cannot retrieve definition for form bean null
•	Struts Tiles Tutorial (free Struts training)
•	Where do I download Tomcat 4 0 6?
•	Data Access Object (DAO) pattern, example DAO 's
•	Where to download Tomcat v 4 1 24 from?
•	Tomcat 5 0 16 Requested resource not available
•	Oracle Connection Pooling in 3 2 2
•	Servlet : Session invalidate
•	Servlet action is currently unavailable
•	Tomcat/Struts Unicode Encoding/Decoding problems
•	Tomcat and webapplication specific java library path
•	Running a Simple JMS Example
•	Mapping in workers2 properties
•	org apache jasper JasperException
•	Cannot find message resources under key org apache struts action MESSAGE
•	problem with html:text bean throwing exception
•	Cannot find message resources under key org apache struts action MESSAGE
•	invalid direct reference problem with solution
•	Tool for jsp debug Try Sysdeo Eclipse Plugin
•	Tomcat 5 Cannot load JDBC driver class 'null ' SQL state: null
•	weblogic ejbc
•	java properties file
•	Jboss 3 2 3 Coyote Can 't re
•	Tomcat 5, Apache2 and mod jk2 integration problem
•	JBoss example problem new to J2EE
•	url string for connecting jboss to oracle
•	Value attribute of <html:checkbox
•	javax servlet ServletException: BeanUtils populate
•	HTTP Status 404 The requested resource is not available
•	5 0 18: Windows XP Pro vs Windows 2000

RES: Design issue for MDB and JDBCs

RES: Design issue for MDB and JDBCs

2003-08-21 - By Tedi Zanfolim

Back
IMHO, if you don�t have any requirements regarding transaction decoupling
from getting the message and updating the database, you could encapsulate
the data processing in a POJO (that would in turn use DAO to access the
database) and achieve the same code reuse mentioned in the early posts. No
need for using a SLSB if you do not have aditional transaction requirements.

HTH,

Tedi

-- --Mensagem original-- --
De: Moore, Gary [mailto:gmoore@(protected)]
Enviada em: Thursday, August 21, 2003 10:12
Para: J2EEPATTERNS-INTEREST@(protected)
Assunto: Re: Design issue for MDB and JDBCs

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)

Esta mensagem, incluindo seus anexos, pode conter informa��o confidencial
e/ou privilegiada. Se voc� recebeu este e-mail por engano, n�o utilize,
copie ou divulgue as informa��es nele contidas. E, por favor, avise
imediatamente o remetente, respondendo ao e-mail, e em seguida apague-o.
Este e-mail possui conte�do informativo e n�o transacional. Caso necessite
de atendimento imediato, recomendamos utilizar um dos canais dispon�veis:
Internet Banking <http://www.bankboston.com.br> , BankBoston por telefone
<http://www.bankboston.com.br/bpt> ou ag�ncia/representante de atendimento
de sua conveni�ncia. Agradecemos sua colabora��o.
This message, including its attachments, may contain confidential and/or
privileged information. If you received this email by mistake, do not use,
copy or disseminate any information herein contained. Please notify us
immediately by replying to the sender and then delete it. This email is for
information purposes only, not for transactions. In case you need immediate
assistance, please use one of the following channels: Internet Banking
<http://www.bankboston.com.br> , BankBoston by phone
<http://www.bankboston.com.br/bpt> or branch/relationship manager at your
convenience. Thank you for your cooperation.

====================================================================
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)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859 (See http://iso-8859.ora-code.com)-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RES: Design issue for MDB and JDBCs</TITLE>
</HEAD>
<BODY>

IMHO, if you don�t have any requirements regarding transaction
decoupling from getting the message and updating the database, you could
encapsulate the data processing in a POJO (that would in turn use DAO to access
the database) and achieve the same code reuse mentioned in the early posts. No
need for using a SLSB if you do not have aditional transaction requirements.

HTH,


Tedi


-- --Mensagem original-- --
 De: Moore, Gary [<A HREF="mailto:gmoore@(protected)">mailto
:gmoore@(protected)</A>]
 Enviada em: Thursday, August 21, 2003 10:12
 Para: J2EEPATTERNS-INTEREST@(protected)
 Assunto: Re: Design issue for MDB and JDBCs

 

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 [<A HREF="mailto:dhirenm@(protected)">mailto
:dhirenm@(protected)</A>]
 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 [<A HREF="mailto:icunko@(protected)
.COM">mailto:icunko@(protected)</A>]
 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 [<A HREF="mailto:ivy12see@(protected)"
>mailto:ivy12see@(protected)</A>]
 > 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: <A HREF="http://www.corej2eepatterns.com"
TARGET="_blank">http://www.corej2eepatterns.com</A>
 J2EE BluePrints: <A HREF="http://java.sun.com/blueprints
/corej2eepatterns" TARGET="_blank">http://java.sun.com/blueprints
/corej2eepatterns</A>
 List Archive:
 <A HREF="http://archives.java.sun.com/archives/j2eepatterns
-interest.html" TARGET="_blank">http://archives.java.sun.com/archives
/j2eepatterns-interest.html</A>
 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: <A HREF="http://www.corej2eepatterns.com"
TARGET="_blank">http://www.corej2eepatterns.com</A>
 J2EE BluePrints: <A HREF="http://java.sun.com/blueprints
/corej2eepatterns" TARGET="_blank">http://java.sun.com/blueprints
/corej2eepatterns</A>
 List Archive:
 <A HREF="http://archives.java.sun.com/archives/j2eepatterns
-interest.html" TARGET="_blank">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"
TARGET="_blank">http://www.corej2eepatterns.com</A>
 J2EE BluePrints: <A HREF="http://java.sun.com/blueprints
/corej2eepatterns" TARGET="_blank">http://java.sun.com/blueprints
/corej2eepatterns</A>
 List Archive: <A HREF="http://archives.java.sun.com/archives
/j2eepatterns-interest.html" TARGET="_blank">http://archives.java.sun.com
/archives/j2eepatterns-interest.html</A>
 Unsubscribing: email "signoff J2EEPATTERNS-INTEREST"
to listserv@(protected)

 

Esta mensagem, incluindo seus anexos, pode conter informa��o
confidencial e/ou privilegiada. Se voc� recebeu este e-mail por engano, n�o
utilize, copie ou divulgue as informa��es nele contidas. E, por favor, avise
imediatamente o remetente, respondendo ao e-mail, e em seguida apague-o. Este e
-mail possui conte�do informativo e n�o transacional. Caso necessite de
atendimento imediato, recomendamos utilizar um dos canais dispon�veis: 
<A HREF="http://www.bankboston.com.br">Internet Banking</A> , <A HREF="http://www.bankboston.com.br/bpt">
BankBoston por telefone</A> ou ag�ncia
/representante de atendimento de sua conveni�ncia. Agradecemos sua colabora��o.

This message, including its attachments, may contain
confidential and/or privileged information. If you received this email by
mistake, do not use, copy or disseminate any information herein contained.
Please notify us immediately by replying to the sender and then delete it. This
email is for information purposes only, not for transactions. In case you need
immediate assistance, please use one of the following channels: <A HREF=
"http://www.bankboston.com.br">Internet Banking</A>
 ,  <A HREF="http://www.bankboston.com.br/bpt">BankBoston by phone</A> or branch/relationship
manager at your convenience. Thank you for your cooperation.

</BODY>
</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)