Karthik, Could you please tell me where I can find articles, sample codes, etc about ValueObjectAssembler ?
-Benoit. -----Original Message----- From: Karthikeyan M [mailto:[EMAIL PROTECTED]] Sent: 06 February 2002 02:51 To: [EMAIL PROTECTED] Subject: Re: EJB and Stored-Procedures Hi Ted, You raised a good point and I completely agree with you. We use stored procs to speed up database intensive operations, through a SLSB-->ValueObjectAssembler as java object (persistence layer) model. I really don't know if anyone has tried EB & stored proc combination, and would like to hear their experience. -karthik. Ted Neward wrote: > Agreed. Using the stored proc presents problems if you use Entity Beans to > access the data. I argue that you don't need the entity beans if you use > stored proces--stored procedures provide much the same encapsulation that an > Entity Bean provides, no? How many layers of encapsulation does a given > project really need, and should the data encapsulation layer be spread > across two (or more) machines? > > 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: Monday, February 04, 2002 4:37 PM > Subject: Re: [EJB-INT] EJB and Stored-Procedures > > > The point I was raising is that you would violate the data encapsulation > that > > the Entity Beans provide, if you use stored procs to access the same data > > (assuming this stored proc is used by some other EJB). This will not make > any > > difference if the stored procs perform read-only operations or doesn't > access > > data maintained by other EBs. But, if they change the data that an entity > bean > > is supposed to provide access to, then you might be in trouble. > > > > -karthik. > > > > Ted Neward wrote: > > > > > 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".
