> > If I am not using EJbs , why that would be silly. > > Where I will commit my > > transaction. > > If you are not using EJBs, you still have a > transaction context. The EJB model simply gives you > the option of having the container manage the > transaction for you. A transaction context is a > fundamental component of an RDBMS. It gives your > database session the ACID properties. So you will call > your transaction commit at the end of the logical code > segment that initiated your transaction, whether it is > in a local Java Class in a Swing application or in a > servelt. Yes i agree with that . What about non transaction clients like jsp. Either you change the code and directly call SPs under transaction context . Or call session beans as facade and let Container manage the transaction for you. Isnt a better design ?
> > > What about the role based security which you can set > > in DD. Say some users > > /clients are not allowed to call some fns. By > > security I dont mean if user > > is having right to call particular SP or not. I am > > talking of higher > > level/business level security. > > Once again, the use of SPs with Entity (or Session) > beans does not affect any of this. Why I will want to use SPs with CMP Ejbs. I can use them with BMPs > It is simply an > alternate mechanism by which data is transmitted back > and forth from the database to the bean. >Your > Deployment Descriptor's security settings are not > joined at the hip to the persistence settings in the > same. Could not get this.?? Why I will worry that particular user can execute a SP or not. I will simply set the method permissions in DD which call those SPs. > > > The question is to use SPs or entity ejb not sql or > > SPs > > I guess I started out this thread by trying to point > out that you are comparing apples and oranges. May be as you think. > > --- Ashwani Kalra <[EMAIL PROTECTED]> wrote: > > > No No No ! > > ????? > > > > > > > > Does anyone on this list actually use stored > > > procedures ? > > We have used in in our last project > > > > > > > > When you invoke a stored procedure, it > > participates in > > > the current transaction identically to a dynamic > > or > > > embedded SQL statement. > > From where that transaction context comes if I dont > > use session beans etc > > with transaction attributes set. > > > > (Yes, you can mess it up by > > > issuing a commit or a rollback in the SP, but that > > > would be silly.) > > > > If I am not using EJbs , why that would be silly. > > Where I will commit my > > transaction. > > > > > > 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. > > > > What about the role based security which you can set > > in DD. Say some users > > /clients are not allowed to call some fns. By > > security I dont mean if user > > is having right to call particular SP or not. I am > > talking of higher > > level/business level security. > > > > > > > > My new mantra: SQL ISOMORPHIC TO SP > > The question is to use SPs or entity ejb not sql or > > SPs > > > > > > > > > > file://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 > > > > > > === 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".
