Nicholas, tough I agree that in most cases this mixed combination works wonders, it presents three problems:
1) Business logic is fragmented. Hence, when changing DBs you're in for some trouble. Granted, if you're part of the IT staff on a company, that won't be much of a problem, but if you're building re-usable components(with the purpose of selling them afterwards in a component marketplace such as Flashline) then you're in for a lot of trouble. 2) The strain on the database is higher. That compromises your ability to scale both up and out, one of the goals in every TP engine built so far. Tuxedo[CORBA] (built by BEA), MTS[COM+] (Microsoft), and the miriad of J2EE servers allow for the application assembler to redefine the physical architecture of a system that uses this component, leveraging ease of scalability, not to mention cost. 3) Not all of the persistence managers are RDBMS. Many RDBMSs of choice do not allow SPs and/or some do not compile SPs. On the other hand, if you're just using SPs to perform CREATE, INSERT, DELETE, UPDATE statements with no business logic on them, _most_ appservers won't take a big hit in performance since they will use PreparedStatement. Most important RBDMS will compile the statement, and also store it temporarily as long as the connection is alive. Since connections are pooled, the differences in speed of execution between using SPs and using PreparedStatements is negligible. In the near future, you could also expect that the appservers compile many of the auto-generated SQL statements into SPs as well. Bottom line is, while in your particular situation usage of SPs means no hassle but actual speed gains, then go ahead (and knock yourself out ;-) ) but from a service/component provider POV, like us here at CodeFoundry, the choice must be done carefully for each case. My 2c, Juan Pablo Lorandi Chief Software Architect Code Foundry Ltd. [EMAIL PROTECTED] Barberstown, Straffan, Co. Kildare, Ireland. Tel: +353-1-6012050 Fax: +353-1-6012051 Mobile: +353-86-2157900 www.codefoundry.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Nicholas > Sent: Wednesday, July 17, 2002 11:42 AM > To: [EMAIL PROTECTED] > Subject: Re: Why Ejb? > > > 100% portability is an illusion. Consider CMP and one > must conclude that porting from one app server to > another will come with a series of head aches > regenerating all the proprietary extended descriptors. > > In this event, it could be argued that BMP offers a > higher degree of portability, if not ease of use, > since you have a higher degree of control over the > actual SQL that is issued. Portability is in the eye > of the porter. > > My point about SPs is that the Java code itself is > better abstracted from the underlying database > structure when it simply calls a CallableStatement and > passes parameters. Admitedly, the downside is that the > SPs themselves have to be regeneratred upon switching > databases, but if you have anything like a serious > application, and you are switching databases, that will the > least of you worries. > > Anyways, I believe the trend is that medium to large > sized companies (if not all companies) tend to have > one standardized database (generally) for J2EE back > ending, but they switch J2EE engines like they change > their underwear.J2EE licenses are quite cheap compared > to DB licenses. > > > //Nicholas > > > --- John Harby <[EMAIL PROTECTED]> wrote: > > But they aren't portable across database vendors so > > if this > > is an issue you should avoid stored procedures. > > > > I'm also not sure exactly what "ISOMORPHIC" means in > > this > > context. Actually the functionality of stored > > procedures > > would comprise a superset of the functionality of > > plain SQL. > > For example in Oracle take a look at DBMS_PIPE. > > > > > > >From: Nicholas <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: [EMAIL PROTECTED] > > >Subject: Re: Why Ejb? > > >Date: Tue, 16 Jul 2002 14:02:44 -0700 > > > > > >No No No ! > > > > > >Does anyone on this list actually use stored > > >procedures ? > > > > > >When you invoke a stored procedure, it participates > > in > > >the current transaction identically to a dynamic or > > >embedded SQL statement. (Yes, you can mess it up by > > >issuing a commit or a rollback in the SP, but that > > >would be silly.) So, when you start a JTA managed > transaction, calls > > >to stored procedures are still within the context of that > > >transaction. They are > > not > > >subject to different rules. > > > > > >Moreover, the same goes for security (in most > > >databases). SPs do not have any magic security > > >override, except that users may have permission to > > >issues SP requests, but not have access to the > > >underlying tables/views/other SPs. This does not > > >affect the security model in J2EE at all. > > > > > >My new mantra: SQL ISOMORPHIC TO SP > > > > > >//Nicholas > > >--- Ashwani Kalra <[EMAIL PROTECTED]> wrote: > > > > You will have to use wrapper/facade in SLSB/SFSB > > > > from which you can take > > > > advanatage of the transactions and security. You > > can > > > > manage the transaction > > > > in SPs also and propagate errors to the session > > bean > > > > methods. > > > > Scalability issue will then shift to session > > beans. > > > > > > > > ----- Original Message ----- > > > > From: "Vikram Naik" <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Tuesday, July 16, 2002 3:46 PM > > > > Subject: Re: Why Ejb? > > > > > > > > > > > > > Hi, > > > > > Thanks for the quick reply... > > > > > Apart from getting generated SQL's > > what > > > > about the transactions > > > > and > > > > > scalability ???? > > > > > > > > > > Vikram Naik > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: A mailing list for Enterprise JavaBeans > > > > development > > > > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > > > Ashwani Kalra > > > > > Sent: Tuesday, July 16, 2002 3:19 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: Why Ejb? > > > > > > > > > > Two reasons : > > > > > 1.EJB(cmp) makes code independent of the > > Database. > > > > > 2. You dont have to code sql queries for > > > > inserting/updating etc. > > > > > > > > > > If you already have Sps then you can > > completely > > > > avoid Entity EJBs and use > > > > > DAO to call SPs. > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > Cheers > > > > > Ashwani Kalra > > > > > http://www.geocities.com/ashwani_kalra/ > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Vikram Naik" <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > Sent: Tuesday, July 16, 2002 3:22 PM > > > > > Subject: Why Ejb? > > > > > > > > > > > > > > > > Hello All, > > > > > > > > > > > > Why should we opt of EjBs when stored > > procedures > > > > can give us better > > > > > > performance? > > > > > > > > > > > > Your opinions will be highly appreciated. > > > > > > > > > > > > Thanks & Regards, > > > > > > Vikram Naik > > > > > > > > > > > > > > > > > > > > > > > > >============================================================= > ========== > >==== > > > > > > 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". > > > > > > > > > > > > >===== > > >Nicholas Whitehead > > >Home: (973) 377 9335 > > >Cell: (201) 615 2716 > > >Work: (212) 622 5639 > > >[EMAIL PROTECTED] > > > > > >__________________________________________________ > > >Do You Yahoo!? > > >Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com > > > > > > >============================================================= > ========== > >==== > > >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". > > > > > > > > > > > _________________________________________________________________ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com > > === message truncated === ===== Nicholas Whitehead Home: (973) 377 9335 Cell: (201) 615 2716 Work: (212) 622 5639 [EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com ======================================================================== === 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".
