OR, you toss EJB altogether and just call the stored procs directly from
your middleware layer (servlets/JSPs in the canonical Sun model). Since the
forthcoming JDBC 3.0 Spec requires/suggests that vendors provide connection
pooling directly inside the driver, and since the middleware (servlet/JSP)
layer automatically provides a centralized place from which connections can
be pooled, I fail to see what EJB buys you at this point.
Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
----- Original Message -----
From: "Ashwani Kalra" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 01, 2002 2:51 AM
Subject: Re: [EJB-INT] EJB and Stored-Procedures
> There is no other choice then to use DAO IMO. if you want to use stored
> procedures. Or other way is if you want to use the app server features
then
> you can go for BMP. There you have all the control in your hand.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Cheers
> Ashwani Kalra
> Sr. Mem. Dev. Staff
> Aithent Technologies
> India
> http://www.geocities.com/ashwani_kalra/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Friday, February 01, 2002 2:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB and Stored-Procedures
>
>
> All,
>
> One of the reasons why we use stored proc, is for
> security reason. No users have an INSERT, UPDATE, or DELETE
> access, they are DBA ( and developer ) privilege access.
> The other one is, as Ted wrote, is for speed issues when
> retrieving data.
> Our stored proc could be just a single SELECT statement,
> or a very complex one, i.e. create one temp table ( or more ),
> grouping, sorting, do a bit calculation, put the result into
> another temp table, indexing, etc, etc.
>
> Any other ideas please ?
>
> Thanks,
> Benoit Aumars.
>
>
> -----Original Message-----
> From: Danny [mailto:[EMAIL PROTECTED]]
> Sent: 01 February 2002 03:03
> To: [EMAIL PROTECTED]
> Subject: Re: EJB and Stored-Procedures
>
>
> I like the model Direct Access Objects --> Stored Procedure -->DB
because:
> 1) Generally speaking developers who do nothing but database work are more
> likely to code more efficient database access than developers who are
> focused on J2EE. This assumes that you have a database group that is
> developing the stored procedures.
> 2) It's not too difficult to write a code generator to generate the DAO
> layer from meta data for the stored procedures. I've done this before and
> this worked very well. The DAOs can be generated so they free the
software
> developers from having to know anything about JDBC, SQL, and how to
properly
> get and release a (pooled) database connection.
> 3) As of to date, the DAO --> Stored Procedure --> DB model will
generally
> outperform EJBs that try to accomplish the same thing. If someone has a
> counter example that's real and not hypothectical about the performance I
> would love to hear it.
> 4) I find CMP QL to be much more restrictive than SQL. I also find
working
> with SQL in a stored procedure more straight forward than working with CMP
> QL in an XML file.
>
> Ask me if I would use the CMP(EJB)-->DB Architecture or SS Java Beans -->
> Stored Procedure --> DB, why the CMP(EJB)-->DB Architecture of course.
It's
> much cooler to work on. :) Actually, I currently use CMPs for database
> updates and DAOs for list retrievals.
>
> my 1c
> Danny
>
> ----- Original Message -----
> From: "Raja, Srinivasan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, January 31, 2002 1:05 PM
> Subject: Re: EJB and Stored-Procedures
>
>
> > Can one favor
> >
> > CMP(EJB)--> DB Architecture (or)
> >
> > SS Java Beans --> Stored Procedure --> DB
> >
> > or does it vary business component to business component?
> >
> > Your views pls.
> > Sri
> >
> >
> > -----Original Message-----
> > From: Ted Neward
> > To: [EMAIL PROTECTED]
> > Sent: 1/31/02 2:36 PM
> > Subject: Re: EJB and Stored-Procedures
> >
> > How is this any different from normal entity beans? The only difference
> > between a normal EB and one using a stored proc is that the stored proc
> > will
> > be faster about retrieving its data.
> >
> > Ted Neward
> > {.NET || Java} Course Author & Instructor, DevelopMentor
> > (http://www.develop.com)
> > http://www.javageeks.com/tneward
> >
> > ----- Original Message -----
> > From: "Karthikeyan M" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, January 31, 2002 9:26 AM
> > Subject: Re: [EJB-INT] EJB and Stored-Procedures
> >
> >
> > > Also,
> > >
> > > Shouldn't the decision on how the entities handle the data be made
> > carefully
> > > when stored procs are involved. Stored procedure is more like a
> > background
> > > access to data that an entity bean is supposed to provide uniform
> > access.
> > If a
> > > stored procedure alters the data of another entity bean, what will
> > happen
> > the
> > > next time someone invokes business methods on the other entity bean?
> > This
> > is
> > > more so when optimizations are involved in how the ejbLoad() and
> > ejbStore() are
> > > executed.
> > >
> > > -karthik.
> > >
> > > Dmitri Colebatch wrote:
> > >
> > > > afaik none of the CMP engines around will elt you map to stored
> > procedures,
> > > > but I cant see any reason why a BMP entity bean couldn't use them.
> > I'm
> > > > assuming that the stored procedures will achieve the same
> > functionality
> > as
> > > > insert/update etc.
> > > >
> > > > the only thing I can think of is that you might find you are forced
> > into
> > > > using very coarse entity beans because of the stored procedure setup
> > (I"m
> > > > assuming they prevent you from breaking any foreign key constraints
> > etc.).
> > > >
> > > > my 2c
> > > >
> > > > cheers
> > > > dim
> > > >
> > > > ----- Original Message -----
> > > > From: "Benoit Aumars" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Friday, February 01, 2002 12:34 AM
> > > > Subject: EJB and Stored-Procedures
> > > >
> > > > > Hi,
> > > > > I hope someone might give me some comments about how a
> > > > > stored-procedure can be used with an entity bean.
> > > > >
> > > > > I have an application which use a database with the following
> > rules :
> > > > > 1. no users have an INSERT, UPDATE, or DELETE access into the
> > database.
> > > > > 2. put every SQL statement, i.e. INSERT, UPDATE, DELETE, or
> > SELECT,
> > > > into
> > > > > a
> > > > > stored-procedure.
> > > > > 3. all stored-procedures are owned by DBO.
> > > > > 4. users are only allowed to execute a SELECT statement or
> > > > > run/execute a stored-procedure.
> > > > >
> > > > > Here are my questions :
> > > > > a. how to use a stored-procedure with an entity bean ?
> > > > > b. the database contains about 125 tables, with about 10 tables
> > > > contains
> > > > > more
> > > > > than 10.000 records. How this can be 'mapped' ?
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Benoit Aumars.
> > > > >
> > > > >
> > > >
> > ========================================================================
> > ===
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > the
> > > > body
> > > > > of the message "signoff EJB-INTEREST". For general help, send
> > email
> > to
> > > > > [EMAIL PROTECTED] and include in the body of the message
> > "help".
> > > > >
> > > >
> > > >
> > ========================================================================
> > ===
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> > the
> > body
> > > > of the message "signoff EJB-INTEREST". For general help, send email
> > to
> > > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> > >
> > ========================================================================
> > ===
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > > of the message "signoff EJB-INTEREST". For general help, send email
> > to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> > >
> >
> > ========================================================================
> > ===
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
> ************************************************************
> JLT Management Services Limited
> 6 Crutched Friars, London EC3N 2PH. Co Reg No 1536540
> Tel: (44) (0)20 7528 4000 Fax: (44) (0)20 7528 4500
> http://www.jltgroup.com
> ------------------------------------------------------------
> The content of this e-mail (including any attachments) as
> received may not be the same as sent. If you consider that
> the content is material to the formation or performance of
> a contract or you are otherwise relying upon its accuracy,
> you should consider requesting a copy be sent by facsimile
> or normal mail. The information in this e-mail is
> confidential and may be legally privileged. If you are not
> the intended recipient, please notify the sender immediately
> and then delete this e-mail entirely - you must not retain,
> copy, distribute or use this e-mail for any purpose or
> disclose any of its content to others.
>
> Opinions, conclusions and other information in this e-mail
> that do not relate to the official business of JLT
> Management Services Limited shall be understood as neither
> given nor endorsed by it. Please note we intercept and
> monitor incoming / outgoing e-mail and therefore you should
> neither expect nor intend any e-mail to be private in nature.
>
> We have checked this e-mail for viruses and other harmful
> components and believe but not guarantee it virus-free prior
> to leaving our computer system. However, you should satisfy
> yourself that it is free from harmful components, as we do
> not accept responsibility for any loss or damage it may
> cause to your computer systems.
> ************************************************************
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
