RE: RE: Stored procedures and J2EE
Yep that's right, but only in an environment where you have the option to connect to the middle layer with any platform you like. Sometimes you haven't and that weighs into the equation as well. Guess my point is that an architecture caries some pragmatism as well. N-tier is not a goal on itself although it almost looks like Gartner cs. would like us to see it that way. Their point was great when nobody was thinking about separating data / business and views, but now we have to build systems and not architectures. FE -- and yes we do have to think about the future when building systems. On Sunday, September 09, 2001 7:46 AM, Troy Wong [SMTP:[EMAIL PROTECTED]] wrote: The whole point of n-tier distributed programming is to keep business logic outside of the database layer. Stored Procedures do have performance benefits, but it's much better from a design perspective to keep all logic in the middle layer and leave the database as a dumb persistence layer. Some would say that it's better to incorporate all the logic in the data layer and so multiple applications can call it without need to reduplicate code. But the same thing can be said of having the logic reside in the middle layer, where you also have the benefits of a strong OO machine independent language. - Brian Chan ([EMAIL PROTECTED]) -Original Message- From: Frank Eggink [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Subject: RE: Stored procedures and J2EE Date: Sat Sep 08 08:07:53 GMT 2001 Is it correct to state that from a performance and design perspective using stored procedures is helpfull if you need access from outside the J2EE environment? If no out side access is necessary, the stored procedures are likely to be helpfull for perfomance if they filter out a lot of data or when you are using recursive logic (this way you are reducing the overhead of the remote calls), or am I missing a point with respect to performance differences between Stored Procedures and plain old SQL? Further more I realize now Stored Procedures are an interesting option in case of severe security requirements. You can differentiate access constraints to the Stored Procedures and minimise the amount off people / systems that have full access to you system. FE On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile) [SMTP:[EMAIL PROTECTED]] wrote: I (empirically) reached the same conclusion; but instead of dropping CMP, we provided performance improvements ON TOP of the EJB's (VO's and VO caches). Thank god we did it this way, because the DB can't scale as easily as the app-server cluster. My 2c, JP -Original Message- From: Rian Schmidt [mailto:[EMAIL PROTECTED]] Sent: Jueves, 06 de Septiembre de 2001 12:51 To: Orion-Interest Subject: Re: Stored procedures and J2EE I'm interested as to how you can say this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say there's absolutely no hit on performance not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The mailto:[EMAIL PROTECTED] elephantwalker To: Orion-Interest mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. File: ATT0.html
RE: Stored procedures and J2EE
Is it correct to state that from a performance and design perspective using stored procedures is helpfull if you need access from outside the J2EE environment? If no out side access is necessary, the stored procedures are likely to be helpfull for perfomance if they filter out a lot of data or when you are using recursive logic (this way you are reducing the overhead of the remote calls), or am I missing a point with respect to performance differences between Stored Procedures and plain old SQL? Further more I realize now Stored Procedures are an interesting option in case of severe security requirements. You can differentiate access constraints to the Stored Procedures and minimise the amount off people / systems that have full access to you system. FE On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile) [SMTP:[EMAIL PROTECTED]] wrote: I (empirically) reached the same conclusion; but instead of dropping CMP, we provided performance improvements ON TOP of the EJB's (VO's and VO caches). Thank god we did it this way, because the DB can't scale as easily as the app-server cluster. My 2c, JP -Original Message- From: Rian Schmidt [mailto:[EMAIL PROTECTED]] Sent: Jueves, 06 de Septiembre de 2001 12:51 To: Orion-Interest Subject: Re: Stored procedures and J2EE I'm interested as to how you can say this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say there's absolutely no hit on performance not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The mailto:[EMAIL PROTECTED] elephantwalker To: Orion-Interest mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. File: ATT0.html
RE: RE: Stored procedures and J2EE
The whole point of n-tier distributed programming is to keep business logic outside of the database layer. Stored Procedures do have performance benefits, but it's much better from a design perspective to keep all logic in the middle layer and leave the database as a dumb persistence layer. Some would say that it's better to incorporate all the logic in the data layer and so multiple applications can call it without need to reduplicate code. But the same thing can be said of having the logic reside in the middle layer, where you also have the benefits of a strong OO machine independent language. - Brian Chan ([EMAIL PROTECTED]) -Original Message- From: Frank Eggink [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Subject: RE: Stored procedures and J2EE Date: Sat Sep 08 08:07:53 GMT 2001 Is it correct to state that from a performance and design perspective using stored procedures is helpfull if you need access from outside the J2EE environment? If no out side access is necessary, the stored procedures are likely to be helpfull for perfomance if they filter out a lot of data or when you are using recursive logic (this way you are reducing the overhead of the remote calls), or am I missing a point with respect to performance differences between Stored Procedures and plain old SQL? Further more I realize now Stored Procedures are an interesting option in case of severe security requirements. You can differentiate access constraints to the Stored Procedures and minimise the amount off people / systems that have full access to you system. FE On Thursday, September 06, 2001 8:08 PM, Juan Lorandi (Chile) [SMTP:[EMAIL PROTECTED]] wrote: I (empirically) reached the same conclusion; but instead of dropping CMP, we provided performance improvements ON TOP of the EJB's (VO's and VO caches). Thank god we did it this way, because the DB can't scale as easily as the app-server cluster. My 2c, JP -Original Message- From: Rian Schmidt [mailto:[EMAIL PROTECTED]] Sent: Jueves, 06 de Septiembre de 2001 12:51 To: Orion-Interest Subject: Re: Stored procedures and J2EE I'm interested as to how you can say this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say there's absolutely no hit on performance not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The mailto:[EMAIL PROTECTED] elephantwalker To: Orion-Interest mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. File: ATT0.html
Re: Stored procedures and J2EE
Hi, I think I might add our 2c, even though they are completely against the trend ;). In fact, we don't use EJBs at all, unsing instead Stored Procedures to perform the business logic. When we started, EJB was an, IMHO, inmature technology that forced people to write lots of intermediate classes to get to the point, it forced you to write vendor dependent code, it had a everything is remote philosophy that was pretty inconvenient and good god! it didn't even took into account relationships between tables! After testing EJB with some projects, we dropped it because the tediousness of typing so much code, the need to write embedded SQL or use vendor dependent features and the development cycle of using EJB, which we don't actually enjoy. We ended up using XML, and even though we can generate it from anything that we please (action classes, JSP, even EJB, if we please) we use, most of the time, stored procedures to generate it. Why? Because it's the place closest to the database, so it travels with it, you have compile-time dependencies between your code and the database schema and you have the appropriate tools to acces/manipulate the database. In case we want/need to do some special pre-/post-processing, then Java comes to the rescue and it is used to further refine the request/response. Besides, that means our business logic, based on XML, is independent of ever changing standards and interfaces. We are quite happy with it, and it has also allowed us to divide the work pretty nicely, as I have had some people working on the project, programming the business logic, who didn't know a single word about Java, HTML or the like. And our designer doesn't know what is a table, a bean, the context or anything like that. Warning!! I'm not saying that this is a universal solution and that EJB should be dropped. No. I'm just saying that they are not the only solution and that sometimes, for example in our case, using stored procedures is better for our overall development. We know we might lose some performance in some cases, but we prefer the easiness of development and the independence of our code. Just my 2c, D. PD: I follow the EJB spec anyway, and I know EJB2.0 solves partially some issues that where some of the reasons why we dropped it, but I for us it's still too little to late.
RE: Stored procedures and J2EE
A bean is just a representation of data in a datastore with a collection of finder and business methods. You can use cmp's to access data which is already in a datastore. Astateless session beancan be used to fire off your create procedures, and this slsb can be in your cmp create (or not, for that matter). As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. If you are doing this to filter your output or because you need custom joins, etc. there are much easier ways to do this...such as using a custom finder method in orion (its a five minute job in the orion-ejb-jar.xml file) or a slsb. regards, the elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian DonciulescuSent: Thursday, September 06, 2001 1:41 AMTo: Orion-InterestSubject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business objects fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making the primary key of the child objects table reference the primary key field of the parent objects table. This reference means that the child inherits the fields of the parent. Thus, the constructor of a child object, which is passed all the parameters required for itself and its parents initialization, will call the constructor of its parent passing the appropriate parameters. The question is: How could such constructors be used without conflicting with the create methods of the CMP entity beans? Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: Stored procedures and J2EE
Thanks for your help. The reasonI want to use stored procedures it that we want to make use of a datamodel that we already have. This data-model uses stored procedures intensively. What would you suggest? Keep the data model as is and adapt the J2EE code to it or change the data-model so that we don't use the storedprocedures that much?Christian From: "The elephantwalker" <[EMAIL PROTECTED]> Reply-To: Orion-Interest <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Subject: RE: Stored procedures and J2EE Date: Thu, 6 Sep 2001 02:23:29 -0700 A bean is just a representation of data in a datastore with a collection of finder and business methods. You can use cmp's to access data which is already in a datastore. A stateless session bean can be used to fire off your create procedures, and this slsb can be in your cmp create (or not, for that matter). As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. If you are doing this to filter your output or because you need custom joins, etc. there are much easier ways to do this...such as using a custom finder method in orion (its a five minute job in the orion-ejb-jar.xml file) or a slsb. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian Donciulescu Sent: Thursday, September 06, 2001 1:41 AM To: Orion-Interest Subject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business objects fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making the primary key of the child objects table reference the primary key field of the parent objects table. This reference means that the child inherits the fields of the parent. Thus, the constructor of a child object, which is passed all the parameters required for itself and its parents initialization, will call the constructor of its parent passing the appropriate parameters. The question is: How could such constructors be used without conflicting with the create methods of the CMP entity beans? -- Get your FREE download of MSN Explorer at http://explorer.msn.com Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: Stored procedures and J2EE
Christian, It will make your life more complex, because it sounds like some of your business methods are built into the stored procedures (before j2ee, this was why we used stored procedures!). All in all, the cost of qa/qc on a new data model should be weighed against the cost of maitenance for the old data-modelin the future. Here are steps for a quick and dirty integration with j2ee: 1. create cmp's with the same datafields as your datastore. 2. if store procedures are used to create rows, then use a slsb to do this. You can embed the slsb within your cmp,or not. Typically, slsb's are usedas facades forspecific jdbc/sql actions. Essentially, the same stored procedures are used. 3. Use a slsb as a facade/controllor for all cmp access. Thus business methods which use stored procedures can be used, and if the business methods is in the cmp, then the cmp business method can be used. 4. Modify your cmp finders in your cmp to match the efficiency of the original pl/sql queries...easily done in Orion with the orion-ejb-jar.xml. Over time, you can drop store procedures as your qc verifies the accuracy of business methods in the slsb or cmp. With this approach you can achieve integration with j2ee quickly and the design allows you to migrate to a total j2ee solution in the future. Also, your j2ee client/web front will not have to change as the underlying data-structure is migrated from stored procedures to j2ee. regards, the elephantwalker -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian DonciulescuSent: Thursday, September 06, 2001 6:38 AMTo: Orion-InterestSubject: RE: Stored procedures and J2EE Thanks for your help. The reasonI want to use stored procedures it that we want to make use of a datamodel that we already have. This data-model uses stored procedures intensively. What would you suggest? Keep the data model as is and adapt the J2EE code to it or change the data-model so that we don't use the storedprocedures that much?Christian From: "The elephantwalker" <[EMAIL PROTECTED]> Reply-To: Orion-Interest <[EMAIL PROTECTED]> To: Orion-Interest <[EMAIL PROTECTED]> Subject: RE: Stored procedures and J2EE Date: Thu, 6 Sep 2001 02:23:29 -0700 A bean is just a representation of data in a datastore with a collection of finder and business methods. You can use cmp's to access data which is already in a datastore. A stateless session bean can be used to fire off your create procedures, and this slsb can be in your cmp create (or not, for that matter). As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. If you are doing this to filter your output or because you need custom joins, etc. there are much easier ways to do this...such as using a custom finder method in orion (its a five minute job in the orion-ejb-jar.xml file) or a slsb. regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian Donciulescu Sent: Thursday, September 06, 2001 1:41 AM To: Orion-Interest Subject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business objects fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making the primary key of the child objects table reference the primary key field of the parent objects table. This reference means that the child inherits the fields of the parent. Thus, the constructor of a child object, which is passed all the parameters required for itself and its parents initialization, will call the constructor of its parent passing the appropriate parameters. The question is: How could such constructors be used without conflicting with the create met
Re: Stored procedures and J2EE
I'm interested as to how you cansay this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say "there's absolutely no hit on performance" not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The elephantwalker To: Orion-Interest Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more.
RE: Stored procedures and J2EE
Rian,
If you
access the stored procedures from a slsb, its just like you ran a jdbc from a
stand alone program or a servlet, only you are using the middle-tier to provide
the business method facade to the stored procedure. I would not recommend
accessing the stored procedures through the cmp...use a slsb. If a create in the
cmp is used, and the stored procedure is necessary for the create or postcreate,
use the slsb from the cmp create or postcreate.
An
example of stored procedures is Jive's forum application. It uses stored
procedures directly from jdbc calls. Jives runs the java forums on the sun site.
I believe the code is freely available. I think the message filters are stored
procedures, which means that every access of a forum message goes through a
store procedure from a servlet...and this forum ispretty
darnfastso there should be no bottle neck from using jdbc and store
procedures.
As for
migrating the business methods from the stored procedures to the slsb's, this
can be done more easily if the slsb is used as a facade for the cmp. Thus you
can use business methods which require direct jdbc access (count(), for example
versus a cmp findAll().size()) or cmp access or stored procedures (again, jdbc
access) as necessary for performance.
So...if the architecture is properly implemented, there should be no hit
on performance.
Regards,
the
elephantwalker
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Rian
SchmidtSent: Thursday, September 06, 2001 9:51 AMTo:
Orion-InterestSubject: Re: Stored procedures and
J2EE
I'm interested as to how you cansay this...
we just did a series of tests here to see what the effect of pulling out some
fairly complex stored procedures into CMP beans, and the performance impact
was enormous. We've actually gone the other way, that is, developing
stored procedures for each anticipated database. The fallback is that
the logic is done in the beans, but that is a worst-case scenario. Now,
I realize that this would be considered such bad form in a Sun-controlled
world of pure J2EE that I hesitate to even mention it... but in the real
world, any significant hit on performance is enough to convince us to
denormalize a bit, so to speak.
I don't think that you can say "there's
absolutely no hit on performance" not to use stored procedures, particularly
if that procedure requires repeated queries of the data in a pseudo-recursive
way. Do you really think that any performance hit that we've seen is a
result of poor design? I'm really interested in your
reasoning.
Rian
- Original Message -
From:
The
elephantwalker
To: Orion-Interest
Sent: Thursday, September 06, 2001 2:23
AM
Subject: RE: Stored procedures and
J2EE
As
for distributing your business logic between the datastore and middle
tier...aren't you making your life more complex than it needs to be? There
is absolutely no hit on performance if you pull out all of your business
logic into a slsb or cmp...there's just no need to use store procedures any
more.
RE: Stored procedures and J2EE
I
(empirically) reached the same conclusion; but instead of dropping CMP, we
provided performance improvements ON TOP of the EJB's (VO's and VO caches).
Thank god we did it this way, because the DB can't scale as easily as the
app-server cluster.
My
2c,
JP
-Original Message-From: Rian Schmidt
[mailto:[EMAIL PROTECTED]]Sent: Jueves, 06 de Septiembre de 2001
12:51To: Orion-InterestSubject: Re: Stored procedures
and J2EE
I'm interested as to how you cansay this...
we just did a series of tests here to see what the effect of pulling out some
fairly complex stored procedures into CMP beans, and the performance impact
was enormous. We've actually gone the other way, that is, developing
stored procedures for each anticipated database. The fallback is that
the logic is done in the beans, but that is a worst-case scenario. Now,
I realize that this would be considered such bad form in a Sun-controlled
world of pure J2EE that I hesitate to even mention it... but in the real
world, any significant hit on performance is enough to convince us to
denormalize a bit, so to speak.
I don't think that you can say "there's
absolutely no hit on performance" not to use stored procedures, particularly
if that procedure requires repeated queries of the data in a pseudo-recursive
way. Do you really think that any performance hit that we've seen is a
result of poor design? I'm really interested in your
reasoning.
Rian
- Original Message -
From:
The
elephantwalker
To: Orion-Interest
Sent: Thursday, September 06, 2001 2:23
AM
Subject: RE: Stored procedures and
J2EE
As
for distributing your business logic between the datastore and middle
tier...aren't you making your life more complex than it needs to be? There
is absolutely no hit on performance if you pull out all of your business
logic into a slsb or cmp...there's just no need to use store procedures any
more.
Auto-reply: Re: Stored procedures and J2EE
I will be on vacation with no access to email until September 10, 2001. For issues concerning the Online Studio, please contact Jiong Wang ( [EMAIL PROTECTED] ). For issues concerning device support (including stylesheets), please contact Young Lee ( [EMAIL PROTECTED] ). Thanks, Attila Bodis Development Manager, Mobile Hosting I'm interested as to how you cansay this... we just did a series of tests here to see what the effect of pulling out some fairly complex stored procedures into CMP beans, and the performance impact was enormous. We've actually gone the other way, that is, developing stored procedures for each anticipated database. The fallback is that the logic is done in the beans, but that is a worst-case scenario. Now, I realize that this would be considered such bad form in a Sun-controlled world of pure J2EE that I hesitate to even mention it... but in the real world, any significant hit on performance is enough to convince us to denormalize a bit, so to speak. I don't think that you can say "there's absolutely no hit on performance" not to use stored procedures, particularly if that procedure requires repeated queries of the data in a pseudo-recursive way. Do you really think that any performance hit that we've seen is a result of poor design? I'm really interested in your reasoning. Rian - Original Message - From: The elephantwalker To: Orion-Interest Sent: Thursday, September 06, 2001 2:23 AM Subject: RE: Stored procedures and J2EE As for distributing your business logic between the datastore and middle tier...aren't you making your life more complex than it needs to be? There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more.
RE: Stored procedures and J2EE
Using EJB means that you can use CMP, BMP or an Object/Relation Mapping tool. I have found CMP to be very limited. I have found BMP with stored procedures way moreflexible when working with relational database and I have found Object/Relation mapping even better. An O/R mapping tool like Cocobase allows youdecouple your objects from your data model via dynamic binding. CMP will tightly bind your objects to your data - which according to the Patterns community is a bad thing. My experiencewith CMP leads me to believe that its creators/supporters area religious myopic bunch. First there is EJB 1.0, then EJB 1.1 and now EJB 2.0 which btw cannot handle Primary Key creation via Identity/Sequence column without a hack. In heterogeneous environments where you have multiple applications talking to the same database, thedatabase engine must be in charge of Primary key generation. As for "There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more." It is a fact that static SQL runs faster that dynamic SQL, and (generally) pre-compiled Stored procedures run faster than static SQL. So, in a model that employs multiple tiers, improving the speed in one tier can improve the overall speed of you application, watch out for network I/O though. My 2 cents, Bill G... -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian DonciulescuSent: Thursday, September 06, 2001 1:41 AMTo: Orion-InterestSubject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business object's fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making the primary key of the child object's table reference the primary key field of the parent object's table. This reference means that the child inherits the fields of the parent. Thus, the constructor of a child object, which is passed all the parameters required for itself and its parent's initialization, will call the constructor of its parent passing the appropriate parameters. The question is: How could such constructors be used without conflicting with the create methods of the CMP entity beans? Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: Stored procedures and J2EE
Well I do like R.E.M., and that religion song, but interestingly enough, I don't wear glasses ;). But seriously, I have also tried this both way's. And cmp dev can be done in 1/4 the time...see below for performance comparisons. Take a look at McGouphlin's column on pk generation in the Flashzone. You can use orion's home-grown pk generation (this is fast and works everytime, and is based upon the database ;)), or you can use slsb's and the database to create your pk's. Fast and safe, and no triggers. Sql finds with joins and the like will always be with us, but these are fast and easy to do in orion (see the orion-ejb-jar.xml doc's) and where necessary slsb's can be used. oo mapping is also easy to do with orion (using Set and Collection's are a one line affair in the cmp ejb). There is a place for stored procedures...but their need is usually very specific. However, its important that implementers stay away from stored procedures as a solution for all performance problems. One jvm in a database cannot compete with 42 or more jvm's in a fully distributed application. In the extreme case of a filter on text output, the app-servers' jvms will leave the database jvm in the dust. Seriously, there is room for agreement here. I was asked a question on a specific project and how to use j2ee to transition an older database from store-procedures to j2ee business methods. I gave a very low risk strategy for doing this. Its important the project members test performance at every step during the project. There is no one and all encompasing solution to bring legacy database applications into the 21st century. j2ee, cmp ejb's, and slsb's are just some of many tools in our quiver to solve these problems. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill G Sent: Thursday, September 06, 2001 1:40 PM To: Orion-Interest Subject: RE: Stored procedures and J2EE Using EJB means that you can use CMP, BMP or an Object/Relation Mapping tool. I have found CMP to be very limited. I have found BMP with stored procedures way more flexible when working with relational database and I have found Object/Relation mapping even better. An O/R mapping tool like Cocobase allows you decouple your objects from your data model via dynamic binding. CMP will tightly bind your objects to your data - which according to the Patterns community is a bad thing. My experience with CMP leads me to believe that its creators/supporters are a religious myopic bunch. First there is EJB 1.0, then EJB 1.1 and now EJB 2.0 which btw cannot handle Primary Key creation via Identity/Sequence column without a hack. In heterogeneous environments where you have multiple applications talking to the same database, the database engine must be in charge of Primary key generation. As for There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. It is a fact that static SQL runs faster that dynamic SQL, and (generally) pre-compiled Stored procedures run faster than static SQL. So, in a model that employs multiple tiers, improving the speed in one tier can improve the overall speed of you application, watch out for network I/O though. My 2 cents, Bill G... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian Donciulescu Sent: Thursday, September 06, 2001 1:41 AM To: Orion-Interest Subject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business object's fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making the primary key of the child object's table reference the primary key field of the parent object's table. This reference means that the child inherits the fields of the parent. Thus, the constructor of a child object, which is passed all the parameters required for itself and its parent's initialization, will call the constructor of its parent passing the appropriate parameters. The question is: How could such constructors be used without conflicting with the create methods of the CMP entity beans? Get your FREE download of MSN Explorer at http://explorer.msn.com
RE: Auto-reply: Re: Stored procedures and J2EE
-Original Message- From: ATTILA.BODIS [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 2:27 PM To: Orion-Interest Subject: Auto-reply: Re: Stored procedures and J2EE I will be on vacation with no access to email until September 10, 2001. For issues concerning the Online Studio, please contact Jiong Wang ( [EMAIL PROTECTED] ). For issues concerning device support (including stylesheets), please contact Young Lee ( [EMAIL PROTECTED] ). Thanks, Attila Bodis Development Manager, Mobile Hosting
RE: Stored procedures and J2EE
One jvm in a database cannot compete with 42 or more jvm's in a fully distributed application. In the extreme case of a filter on text output, the app-servers' jvms will leave the database jvm in the dust. That might be true if you had one jvm in one db host, but the reality is that a cluster of db hosts that share state like Sybase ASE have operated within the most intensive applications environments around, like the NYSE for example. Bill G. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of The elephantwalker Sent: Thursday, September 06, 2001 3:00 PM To: Orion-Interest Subject: RE: Stored procedures and J2EE Well I do like R.E.M., and that religion song, but interestingly enough, I don't wear glasses ;). But seriously, I have also tried this both way's. And cmp dev can be done in 1/4 the time...see below for performance comparisons. Take a look at McGouphlin's column on pk generation in the Flashzone. You can use orion's home-grown pk generation (this is fast and works everytime, and is based upon the database ;)), or you can use slsb's and the database to create your pk's. Fast and safe, and no triggers. Sql finds with joins and the like will always be with us, but these are fast and easy to do in orion (see the orion-ejb-jar.xml doc's) and where necessary slsb's can be used. oo mapping is also easy to do with orion (using Set and Collection's are a one line affair in the cmp ejb). There is a place for stored procedures...but their need is usually very specific. However, its important that implementers stay away from stored procedures as a solution for all performance problems. One jvm in a database cannot compete with 42 or more jvm's in a fully distributed application. In the extreme case of a filter on text output, the app-servers' jvms will leave the database jvm in the dust. Seriously, there is room for agreement here. I was asked a question on a specific project and how to use j2ee to transition an older database from store-procedures to j2ee business methods. I gave a very low risk strategy for doing this. Its important the project members test performance at every step during the project. There is no one and all encompasing solution to bring legacy database applications into the 21st century. j2ee, cmp ejb's, and slsb's are just some of many tools in our quiver to solve these problems. Regards, the elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill G Sent: Thursday, September 06, 2001 1:40 PM To: Orion-Interest Subject: RE: Stored procedures and J2EE Using EJB means that you can use CMP, BMP or an Object/Relation Mapping tool. I have found CMP to be very limited. I have found BMP with stored procedures way more flexible when working with relational database and I have found Object/Relation mapping even better. An O/R mapping tool like Cocobase allows you decouple your objects from your data model via dynamic binding. CMP will tightly bind your objects to your data - which according to the Patterns community is a bad thing. My experience with CMP leads me to believe that its creators/supporters are a religious myopic bunch. First there is EJB 1.0, then EJB 1.1 and now EJB 2.0 which btw cannot handle Primary Key creation via Identity/Sequence column without a hack. In heterogeneous environments where you have multiple applications talking to the same database, the database engine must be in charge of Primary key generation. As for There is absolutely no hit on performance if you pull out all of your business logic into a slsb or cmp...there's just no need to use store procedures any more. It is a fact that static SQL runs faster that dynamic SQL, and (generally) pre-compiled Stored procedures run faster than static SQL. So, in a model that employs multiple tiers, improving the speed in one tier can improve the overall speed of you application, watch out for network I/O though. My 2 cents, Bill G... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Cristian Donciulescu Sent: Thursday, September 06, 2001 1:41 AM To: Orion-Interest Subject: Stored procedures and J2EE Is it possible (and recommended) to use stored procedures with the J2EE architecture? We would be interested in creating objects directly into the database, bypassing the create method of the enterprise bean. Is this possible when using CMP (Container Managed Persistence)? If not, in your opinion, which is best: using BMP and stored procedures or using CMP? Example: We have an Oracle DB that uses packages associated to the business objects of the system. These packages contain the PL/SQL methods of the corresponding business objects. Additionally every business object's fields are stored as columns of a specific table. The constructor of a business object is also a method in the associated package. The inheritance relation between two objects is modeled by making
