RE: How are database JOINS achieved with EJBs?
I'm not sure why everyone is under the impression that anything in a database needs to be an entity bean. I never felt this, nor got this from the Java community. I would recommend reading the SUN java Blueprints document. They barely use entity beans at all. It is very well thought out and has excellent recommendations on when to use, and when not to use entity beans. There is really only one time you would use an entity bean, when you have a single row entity that needs to be modified, such as a user account. If you are returning more that one row you are much better off with a session bean that performs JDBC calls to the database. Even when you instantiate an entity bean you don't always need to access it on the client side. You can encapsulate the entity fields into a read only serializable copy. This object can be passed by value to the client. This means that the model object actually lives on the client, only one RMI call to get the object in the first place. Note that in contrast entity beans are passed by reference so that every call to access the fields of the EJB require an RMI call. That is enough of my 2 cents. I really got all this information from the J2EE blueprints from SUN. I cannot recommend this online book enough!! -Steve Rock -Original Message- From: Al Fogleson [mailto:[EMAIL PROTECTED]] Sent: Friday, May 26, 2000 6:21 PM To: Orion-Interest Subject: Re: How are database JOINS achieved with EJBs? - Original Message - Al: YES. I'm starting off with the hypothesis that all database tables should map to EJBs, because that is what all the hype is about. Now, for real world, does it work well? Yes and no. There is a terribly large amount of overhead involved in EJB to begin with, then you start adding all the RMI calls over the network and that adds some load too. In general we try to model our EJB such that we minimize the Entity beans. Certainly they are handy, but let us take a classic example of a person bean. A person also has an address, now addresses dont change much so I really dont see a lot of sense in deploying an address bean that will sit for most of the time in the pool and not be instantiated. So I would just use a regular class (which may get a datasource from the JNDI services) and do this address class using regular JDBC. So yes entity beans work well, but we as a java community have "fooled" ourselves into thinking that if it is a table in a database it should be an entity bean. Is you answer that one should make create an EJB that is not CMP, but rather one supplies a hand crafter SQL command somewhere in its member functions? Yes, you can use bean managed persistence to handle this. In your case it should be rather simple since you seem to have a built in primary key (D) so it would work easy. There are some situations, especially when doing the kinds of things you are talking about where BMP is the only way to go. Because of complex joins or the need for a complex primary key. it does put more work on the bean developer but in some cases it may be the only way to go. Al - att1.htm
Re: How are database JOINS achieved with EJBs?
Hello Al, Al Fogleson wrote: Yes and no. There is a terribly large amount of overhead involved in EJB to begin with Which overhead are you referreing to by this? The overhead involved should be low compared to the optimizations that are done to speed up data access. then you start adding all the RMI calls over the network and that adds some load too Well, EJBs will not always be called remotely to start with. A very common scenario is that you write Servlets/JSPs that communicate with EJBs. Usually you will run your Web components and EJBs on the same servr and no RMI calls will be made. Of course though, if you need the remote access it will be used. But that is an overhead you need no matter what technology. Orion's RMI-transport protocol is very optimized. There are some situations, especially when doing the kinds of things you are talking about where BMP is the only way to go. Because of complex joins or the need for a complex primary key. it does put more work on the bean developer but in some cases it may be the only way to go. Yes, in a few very rare cases you need BMP because of the full control, but whenever you do, stop and think about wether you really need it. In most cases when BMP is used it's not really necesseary. And with BMP, as always, you won't get the performance of CMP and it won't be as simple to change database. Regards, Karl Avedal
Re: How are database JOINS achieved with EJBs?
Karl; Most of the EJB containers I have tried out have multiple instances of a JVM running, thats an awful lot of overhead. We are also running applications where there are up to (and sometimes more) than 100 simultaneous accesses on a bean. Even using clustering there is still an awful load on our cpu's at that rate. unless there is some way to access the bean other than through the home/remote interface I cant think of any instance where a EJB is not accessed remotely. Whether that RMI call is made locally or from a turly remote client (application, applet, what have you) its still an RMI call. i will grant that it will be faster on a local call than on a network call, but it is still an RMI call. (I'll even grant that RMI is faster than Corba IIOP, but I wonder, since the last tests I saw were using straight RMI if that is even true now.) I disagree on the changing databases using BMP. Enterprise level databases all are pretty much standardized on SQl, and as long as you dont use some database specific code to do your stuff in (whether that be calling stored procedures or whatever) you should be able to be portable accross databses using JNDI to get a datasource. I do agree there are not that many cases where BMP is truly necessary however. :) Al - Original Message - From: "Karl Avedal" [EMAIL PROTECTED] To: "Al Fogleson" [EMAIL PROTECTED] Cc: "Orion-Interest" [EMAIL PROTECTED] Sent: Sunday, May 28, 2000 5:01 AM Subject: Re: How are database JOINS achieved with EJBs? Hello Al, Al Fogleson wrote: Yes and no. There is a terribly large amount of overhead involved in EJB to begin with Which overhead are you referreing to by this? The overhead involved should be low compared to the optimizations that are done to speed up data access. then you start adding all the RMI calls over the network and that adds some load too Well, EJBs will not always be called remotely to start with. A very common scenario is that you write Servlets/JSPs that communicate with EJBs. Usually you will run your Web components and EJBs on the same servr and no RMI calls will be made. Of course though, if you need the remote access it will be used. But that is an overhead you need no matter what technology. Orion's RMI-transport protocol is very optimized. There are some situations, especially when doing the kinds of things you are talking about where BMP is the only way to go. Because of complex joins or the need for a complex primary key. it does put more work on the bean developer but in some cases it may be the only way to go. Yes, in a few very rare cases you need BMP because of the full control, but whenever you do, stop and think about wether you really need it. In most cases when BMP is used it's not really necesseary. And with BMP, as always, you won't get the performance of CMP and it won't be as simple to change database. Regards, Karl Avedal
Re: Does Orion eliminate RMI? Was: How are database JOINS achieved with EJBs?
that would be the only case where I can see that you could bypass RMI. How it would be done and maintain within spec would be beyond me. since the client is not run in the container... certainly in the case of a session bean calling Entities yes, but in the case of a web client (servlet or whatever) calling the session bean you are still going to have the RMI overhead. That was my contention. I assumed Karl was speaking of the inter-container calls between Session and Entity beans when he referred to them not being called remotely after I thought about it :) Al - Original Message - From: "Steven Punte" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Sunday, May 28, 2000 7:33 PM Subject: Does Orion eliminate RMI? Was: How are database JOINS achieved with EJBs? Al Fogleson wrote: then you start adding all the RMI calls over the network and that adds some load too Well, EJBs will not always be called remotely to start with. A very common scenario is that you write Servlets/JSPs that communicate with EJBs. Usually you will run your Web components and EJBs on the same servr and no RMI calls will be made. Of course though, if you need the remote access it will be used. But that is an overhead you need no matter what technology. Orion's RMI-transport protocol is very optimized. I agree with Karl that RMI, even on the same machine, is a significant overhead. Think of CPU consumption to serialized and de-serialize member function arguments and return value. When ones' client and EJB container are both on the same machine and in the same process, CAN Orion bypass the RMI protocol here and achieve near optimum performance? It would be like having your cake and eating it too, to have both the Enterprise architecture and near optimum performance in this single server scenario. :-) STeve
Re: How are database JOINS achieved with EJBs?
Al: YES. I'm starting off with the hypothesis that all database tables should map to EJBs, because that is what all the hype is about. Now, for real world, does it work well? Is you answer that one should make create an EJB that is not CMP, but rather one supplies a hand crafter SQL command somewhere in its member functions? STeve Punte e-Business Software Architect Technologent Inc [EMAIL PROTECTED] - Original Message - From: Al Fogleson [EMAIL PROTECTED] To: Steven Punte [EMAIL PROTECTED]; Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, May 23, 2000 6:34 PM Subject: Re: How are database JOINS achieved with EJBs? you can do it the same way using BMP. Although I would be careful, I think we, as programmers have convinced ourselves that if something is in a database it MUST be an entity bean. This attitude seems to prevail all over, even at my work, where I am having a heck of a time convincing people it is just not so, or doesnt have to be :) Al - Original Message - From: "Steven Punte" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Thursday, May 25, 2000 8:52 PM Subject: How are database JOINS achieved with EJBs? Dear EJB Community: Entity java beans pretty much represent a row of data in a database table. If one has: Table XTable Y -- -- A B C DD E F G One commonly executes a SQL command like: select A from X join Y on X.D=Y.D where Y.G ="Bill Clinton" How would one do the equivalent task in an elegant "Enterprise Java Bean" like manner? That is, other than simply writing some member function that performs a JDBC select command like above. Inquiring Minds Want To Know -- STeve Punte e-Business Software Architect Technologent Inc [EMAIL PROTECTED]
Re: How are database JOINS achieved with EJBs?
Porfiriev: I'm not yet that familiar with EJBs. Can you clarify, or re-state you solution below? I don't understand what you are suggesting. Thanks STeve Punte e-Business Software Architect Technologent Inc [EMAIL PROTECTED] - Original Message - From: Porfiriev Sergey [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Cc: Orion-Interest [EMAIL PROTECTED] Sent: Thursday, May 25, 2000 11:47 PM Subject: Re: How are database JOINS achieved with EJBs? Hello Steven, Friday, May 26, 2000, 4:52:00 AM, you wrote: example: Write folowing in yours Home interface or ( deployment orion ejb-jar.xml (full: not included) public static final String findByID_STORE_AND_ID_GRP_ORDER_BY_NAME_query= "full:SELECT PL.Id_Pricelist, PL.Datestart, PL.Datestop, PL.Discount, PL.Id_Product, PL.Id_Status, PL.Itemcomment, PL.Oldprice, PL.Price, PL.Quantity FROM PriceList PL, Product P WHERE PL.ID_PRODUCT=P.ID_PRODUCT AND PL.ID_STATUS'0' AND PL.ID_STATUS IS NOT NULL AND P.ID_STORE=$1 AND P.ID_GRP=$2 ORDER BY P.PRODUCTNAME" public static final String findByID_INVITEM_query= "Id_Value in ( select Id_Value from OrderedValues where Id_InvItem=$1 )"; SP Dear EJB Community: SP Entity java beans pretty much represent a row of data SP in a database table. SP If one has: SP Table XTable Y SP -- -- SP A B C DD E F G SP One commonly executes a SQL command like: SP select A from X join Y on X.D=Y.D where Y.G ="Bill Clinton" SP How would one do the equivalent task in an elegant SP "Enterprise Java Bean" like manner? That is, other SP than simply writing some member function that performs SP a JDBC select command like above.
