Re: Why Entity EJBs?
Hello Juan, What you are seeing is most likely people who have subscribed some time ago forgot about it and now start receiving mail due to the fixed mail problem as of yesterday (see other thread). Could that be it? /Magnus Stenman, the Orion team - Original Message - From: "Juan Lorandi (Chile)" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 1:01 AM Subject: RE: Why Entity EJBs? somebody suscribed a whole lotta of criticalmass people to this list; can't we have a subscribe/unsubscribe confirmation?? JP -Original Message- From: Carla Marcyniuk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:53 PM To: Orion-Interest Subject: RE: Why Entity EJBs? Please take me off this list as I have no interest in this conversation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi (Chile) Sent: Tuesday, March 20, 2001 12:11 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophreni
Re: Why Entity EJBs?
Hi! I fully agree with your opinion. We in our company have decided to use ONLY stateful session beans(SSB) for database access. Yes, it is necessary to create some proprietary persistence stuff, but we see a lot of benefit from it mainly because there is only one instance of SSB per database table (or more tables) for each user. Each finder or query request for database row (also create, delete,..) results only in changing state in appropriate SSB. This solution is very simple. For me the question is why to have separate instances of Entity beans for each database row. All methods are the same for all rows, aren't they? What is changing are the fields. So the same effect could be achieved through changing the state in one instance of session bean which represents one entity (database table,...). Yes, I know that one instance of entity bean can serve many users, but to implement simple task like - FOR EACH Item: Item.price = Item.price + 10. END. - through some collections of thousands or million remote objects is for me inacceptable. Regards Petr - Original Message - From: Johan Lundberg [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 8:22 AM Subject: Why Entity EJBs? Hi The more I study the J2EE technology, the more I wonder why I should use it. The main reasons why I would use it are these: - Forget about the database layer while only using CMP entity beans. - Faster. - Scalable. - Easier to manage transactions. - Clear separation between client-workflow-persistence (JSP - Session beans - Entity beans). In our current system we use simple JSP, JavaBeans and a few connections to our database. We have made a few mistakes but we envisage cleaning up the system by starting from scratch. It is important that we choose the right technology but I get more and more sceptical about the EJB technology. We have experienced, when doing listings from a search page, that reading from the database and instantiating a few beans (not EJBs) takes a long time. The fastest way is to loop the resultset in the JSP-page, but it does have a few drawbacks and I would prefer to use another architecture. I thought that the pooled entity beans would speed up the system and started to study EJB. Then, Richard Monson-Haefel states in his book that listings shall be done directly between the Session bean and the database. Otherwise it would be too slow. I don't want to bother with SQL anymore and I would like to forget about the database layer, but it seems very difficult to get away with this requirement. To communicate between the JSP, the Session beans and the Entity beans, I get advised to use Data Access Objects. If I were to ignore the Monson-Haefel advise I would first create a bunch of Entity beans from a finder method, instantiate a collection of DAOs and send them back to the requesting Session bean. I wonder what kind of performance I would get from this system? I guess that this can become very heavy weight. It will probably become even more heavy weight when n-m OR-mapping becomes available. This will force us into a solution were we would have to use clusters and the scalability features of EJB comes handy. Is this the strategy from Sun - to make us buy more SUN servers? Now, what did I miss? Is there something that I have completely misunderstood? Please tell me what strategy we should use while developing CMP entity beans with Orion's OR-mapping features. I have found that another paradigm and framework that will simplify the development and reduce the amount of SQL-coding. http://jrf.sourceforge.net/ejb.html http://jrf.sourceforge.net/ Why shouldn't we use this framework? Best regards /johan _ Do You Yahoo!? [EMAIL PROTECTED] - skaffa en gratis mailadress p http://mail.yahoo.se
RE: Why Entity EJBs?
I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We tend to use JSP and regular form beans for most of the other workflow stuff, and sometimes we'll have quite complex finder methods in the EJBs that join across several tables. The benefits to EJBs, and specifically orion, for me are: - Database independence: we're deploying on MS SQL Server but it's trivial to deploy to eg. Oracle for scalability or Hypersonic for local testing. - Network independence: I need to change no code to cluster orion on several hosts and also to split its responsibilities between being a web server on one host talking to another orion instance being an app server on another host. - Speed of development: I don't have to worry about how or where my data is being stored - I have orion's _fantastic_ OR mapping to do that for me. It seems to me that the JRF is taking the "best practice" approach, which is a fine and noble thing to do, but then overcomplicating the issue by wandering off into its own specification. All my SQL for each package is in one place (orion-ejb-jar.xml), and I don't have to worry about scalability or portability. If it says J2EE on the box, it'll usually have J2EE in the box. (Apart from the usual niggles with app servers being behind spec - again orion is pretty good for being up-to-date in this regard.) So I have all the benefits of JRF but with the backing of a technology as widely-adopted as J2EE. /two-pence-worth Disclaimer: I don't work for orion, I just love their product. And J2EE has been the most useful technology I've discovered since I picked up OO about 10 years ago! Regards, Dan. ps. That passage in the EJB book about having a session bean talk straight to a database is again (imo) a throwback to the technology being pretty immature and inefficient when the book was written. I have had no problems with orion's ability to manipulate and cache data for me comparably well with direct database access - but with the added benefit of lots of data integrity checking and no SQL on my part. In fact you get two levels of caching - the database and the app server. Date: Tue, 20 Mar 2001 09:22:52 +0100 (CET) From: Johan Lundberg [EMAIL PROTECTED] Subject: Why Entity EJBs? To: Orion-Interest [EMAIL PROTECTED] X-Mailer: Orion ListServer Reply-To: Orion-Interest [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] X-MIME-Autoconverted: from 8bit to quoted-printable by druid.evermind.net id KAA23094 Hi The more I study the J2EE technology, the more I wonder why I should use it.
Re: Why Entity EJBs?
Orion should execute one SQL query for a finder (even with 1000 rows) unless: You're using BMP. You're using exclusive-write-access="false" and are outside of a TX. BMP is less than slim when it comes to SQL activity, we generally recommend CMP unless the condition is exceptional. Another "common mistake" in EJB usage is not using transactions. The same code can generate 100x+ as many calls when run outside of a TX as inside a TX. Why this is specific to EJB is that EJB treats data integrity very carefully, while your "home brewed" (hope that word isnt offensive) access may delay persistance into larger chunks etc (a "semi TX"). So: avoid exclusive-write-access="false" unless absolutely needed, use CMP if possible, and identify where your app is really "TXs" logically but isnt defined to be. What you get: cleaner and more easily abstracted code if all goes well. Transactional (and distributed, stay tuned some longer for that to come clustering doc) cache (it is fairly easy to make a cache, but another issue alltogether to make a transactional cache that scales, totally different tasks). More ease in code migration between programmers since you're closer to the "default", more of the backbone has been provided/standardized. Weakest side of entities as of now: batch updates. No candidate to that one, it is the biggest limitation (but can be worked around). As for "general design standpoint" it is usually not good custom for a vendor to push a practice; but we can say as much as that our recommendations are pretty much in line of those described by Dan North in a recent reply to this thread (CMP, logic in entities that apply to that entity - ignore the recommendation stating that they're simply data storage items, they're objects, and inter-bean logic in sessions). Just a short note... we rarely mix into this category of discussions (the ones bordering on religious beliefs ;) but I thought I'd shed some technical light on some of the issues - everyone's free to chose their own architecture, but it's sad when it's done due to lack of knowledge of architecture X's facts and benefits. Have a nice day! /Magnus Stenman, the Orion team PS. On the issue of "coarse grained" - entities fit perfectly well for fine grained access, but this is a political battle. You may have heard rumours about "local" entities, which consist more or less of entities allover but "allowed for fine grained access" this time. Our current position on that matter is that locals are superflous, what needs to change is just the notion of EJBs always being coarse grained. This is, of course, a very preliminary position. If there turns out to be genuine technical merits for the separation (things that cannot be done feasably via switch tags in the descriptor, see for instance copy-by-value in orion-ejb-jar.xml) that weight enough we'll reposition. /Magnus Stenman, the Orion team - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 6:31 PM Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b)
RE: Why Entity EJBs?
I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot
RE: Why Entity EJBs?
May I suggest an architecture that we are employing without using EJB, but will easily adapt to moving to EJB if need be. First, I can't agree more about getting rid of dealing with the persistence layer. A Java developer generally doesn't want to worry about the SQL, database issues, etc. It would be nice if we had simple methods that would get one or more objects based on some search mask we supply, or store one or more objects. I believe EJB is a step in the right direction to acheive this, when dealing with CMP. However, CMP as I have read about it has limitations, but at the same time allows the application server to make performance enhancements. EJB 2.0 doesn't look very simple to work with and I haven't given it much time as of yet. What I do suggest is something fairly simple. Set up your class structure like so and use a Model 2 front-end archtecture. I have one readily available that handles XSLT processing for you as well. First, you will want to set up folders like so (as per my suggestion, you can do it how you want) com.mycompany.* /src /src/com /src/com/mycompany /src/com/mycompany/ejb /src/com/mycompany/ejb/session /src/com/mycompany/ejb/entity /src/com/mycompany/core /src/com/mycomapny/core/entity /src/com/mycompany/presentation /src/com/mycompany/presentation/actions /src/com/mycompany/presentation/beans /src/com/mycompany/presentation/servlets The above is a start. The /ejb package doesn't necessarily mean EJB, but it assumes EJB is the business logic of your code. Entity EJB package would contain special "beans" that handle the load/store/find capabilities of objects, including any one to one, one to many, and so on. We currently write SQL in these beans and they would basically be BMP in the EJB domain. By simply implementing two interfaces and adding some methods, you turn your version of an entity bean into a CMP (or BMP) EJB entity bean. The ejb/session package is where you put your session "business logic" classes. These two can start off as normal classes, and be turned into EJB session bean classes by implementing two interfaces and adding a few methods to the main session class. As for how you access the "logic"..its quite simple. With my front-end framework or another one called Struts, you use a single entry ControllerServlet for all requests, and call upon action classes (basically servlets that are instantiated and kept in memory via the ControllerServlet) to handle each incoming request. Each action class would create a new stateless session class (before using EJB) or do a JNDI lookup on the EJB session bean (if you move to EJB) to get a reference to a "logic" class. The action class then calls methods of the session class, passing to it objects (Strings, Integer, your own classes, etc) and getting results back. Keep in mind, you should ALWAYS make sure everything you pass to a session class and any results you get back are objects that implement Serializable, so that if and when you do move to EJB, you don't have to figure out a reworking of any given method or class so that it will work. EJB serailizes objects when passing them to and from other classes (such as your front-end action classes or a desktop client program for example). You asked what you get by moving to EJB. If your a small company with a small site, or doing your own stuff that is not very big, I don't think you'll see a significant improvement in performance for your site, nor will you find it as easy to develop with EJB's than if you just put the logic in an action class, a servlet or directly in the JSP. However, what you do get even if you are small, is what I consider "proper" development. You break out your code into easily manageable tiers (and thus your packaging is easier to find classes, organized, etc). You move any and all logic work into a "session" class and ALL database access is done from this class. You remove ALL back-end database ties from any JSP pages, servlets or action classes. Thus, your front-end HTTP based stuff can now be plugged in to any existing database back-end and any database without direct locks to one database. Ofcourse, using JDBC pretty much does this for you too, but by moving ALL database access to session beans (non-EJB parlance this would be session/logic classes, EJB = session beans), you further simplify your development process and a BIG advantage is IF your business grows, you now have a much more manageable code base to hire more developers in to. You can also more easily find problems. Is it a logic problem? Go to a session class. IS it a front-end problem? Go to an action or servlet class. Now, if your a larger organization, especially one that may be acquiring one or more companies, having to work with legacy applications, and integrate with other companies, you get a very nice advantage to moving to EJB. You can now centrally locate ALL of your company's business logic in one place (following the ASP model) and access it from anywhere in the
RE: Why Entity EJBs?
Please take me off this list as I have no interest in this conversation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi (Chile) Sent: Tuesday, March 20, 2001 12:11 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating
RE: Why Entity EJBs?
A! You are absolutely right, and I marvel at my own foolishness! It was something in my code that made it look like finders were issuing n+1 calls. That, combined with my expectation of trouble because this question (about n+1 sql calls for a finder) comes up with some regularity on the ejb-interest mailing list. I don't think many of the (other) appserver vendors have a satisfactory solution. My faith in CMP has been restored. I'm finding that hacking around case-sensitivity in String values is annoying, but it still beats handwriting SQL. Thanks Magnus! It's too bad that Sun doesn't espouse this same line of thought; it's pretty clear to me now that the arguments against fine-grained entities are largely a product of deficient container implementations. This should be a FAQ. Jeff -Original Message- From: Magnus Stenman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 10:33 AM To: Orion-Interest Subject: Re: Why Entity EJBs? Orion should execute one SQL query for a finder (even with 1000 rows) unless: You're using BMP. You're using exclusive-write-access="false" and are outside of a TX. BMP is less than slim when it comes to SQL activity, we generally recommend CMP unless the condition is exceptional. Another "common mistake" in EJB usage is not using transactions. The same code can generate 100x+ as many calls when run outside of a TX as inside a TX. Why this is specific to EJB is that EJB treats data integrity very carefully, while your "home brewed" (hope that word isnt offensive) access may delay persistance into larger chunks etc (a "semi TX"). So: avoid exclusive-write-access="false" unless absolutely needed, use CMP if possible, and identify where your app is really "TXs" logically but isnt defined to be. What you get: cleaner and more easily abstracted code if all goes well. Transactional (and distributed, stay tuned some longer for that to come clustering doc) cache (it is fairly easy to make a cache, but another issue alltogether to make a transactional cache that scales, totally different tasks). More ease in code migration between programmers since you're closer to the "default", more of the backbone has been provided/standardized. Weakest side of entities as of now: batch updates. No candidate to that one, it is the biggest limitation (but can be worked around). As for "general design standpoint" it is usually not good custom for a vendor to push a practice; but we can say as much as that our recommendations are pretty much in line of those described by Dan North in a recent reply to this thread (CMP, logic in entities that apply to that entity - ignore the recommendation stating that they're simply data storage items, they're objects, and inter-bean logic in sessions). Just a short note... we rarely mix into this category of discussions (the ones bordering on religious beliefs ;) but I thought I'd shed some technical light on some of the issues - everyone's free to chose their own architecture, but it's sad when it's done due to lack of knowledge of architecture X's facts and benefits. Have a nice day! /Magnus Stenman, the Orion team PS. On the issue of "coarse grained" - entities fit perfectly well for fine grained access, but this is a political battle. You may have heard rumours about "local" entities, which consist more or less of entities allover but "allowed for fine grained access" this time. Our current position on that matter is that locals are superflous, what needs to change is just the notion of EJBs always being coarse grained. This is, of course, a very preliminary position. If there turns out to be genuine technical merits for the separation (things that cannot be done feasably via switch tags in the descriptor, see for instance copy-by-value in orion-ejb-jar.xml) that weight enough we'll reposition. /Magnus Stenman, the Orion team - Original Message - From: "Jeff Schnitzer" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Tuesday, March 20, 2001 6:31 PM Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP
RE: Why Entity EJBs?
somebody suscribed a whole lotta of criticalmass people to this list; can't we have a subscribe/unsubscribe confirmation?? JP -Original Message- From: Carla Marcyniuk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 5:53 PM To: Orion-Interest Subject: RE: Why Entity EJBs? Please take me off this list as I have no interest in this conversation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Lorandi (Chile) Sent: Tuesday, March 20, 2001 12:11 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I'm using EJB 1.1 CMP; It gives me as much DB independence as I need. I have to rewrite some finders when porting from DB to DB; hopefully EQL will remove this burden too. Orion performs caching of instances, check out exclusive-write-access and validity-timeout atrributes for entity-deployment tag in orion-ejb-jar.xml. However, if you have a distributed environment, cache's like the one in Orion are a threat to data integrity-- so they *must* be deactivated. Also, an orion-dependant feature, the boolean isModified(), which in WLS is called boolean isDirty(), plus a correct use of declarative transactions allow to minimize the impact on the DB. I believe CMP is the way to go, but it is very much server-dependant. The (apparent) poor performance of CMP is due to the need for this solution to address many things we all want from the server, such as data integrity, distribution across hosts of the business logic, declarative transactions and security. There's a price inherent to all this features, and the larger the spec, the higher the price we all must pay, basically, by leveling down. MS's single vendor approach actually levels up, but when they don't have the answers pre-packaged, all crumbles down and somehow we(as developers) must pay for the loses. Eventually, the servers *will* perform as expected, but until the spec matures, we will be stuck with some minor problems. I'm now living in Chile, and the budgets are pretty tight here, but still, the customer'd rather pay for an extra box to scale up than to pay extra to the programmers to do a more optimized job and scale out. I'm aware that this is vastly simplifying the issue, but the point still stands. Perhaps the true problem is that we, all the J2EE developer community, are pushing it too far *and* too broad. This is what happened with CORBA, leaving us with very little common ground. Some servers implement mor of the spec, some less. Some scale(but forbid Singleton's, for instance) and some don't. And there is no single way of making two OTS from two different vendors to cooperate. CORBA was even taller than the Everest, so nobody climbed it. Of course, I also have those rush moments where I wonder why I quitted my older job, but that's definitely not the time to contribute to anything. My 2c, JP -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 1:31 PM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've fou
RE: Why Entity EJBs?
How about using a tool like TopLinks to do BMP for you? Then you can manage the model from a GUI standpoint, and the interfaces, code, descriptors, etc is all written for you. You then simply add in the business logic to session beans and let TopLinks handle the persistence of entity beans. I am not sure that this is how it really works, but I know we are going to be switching to a tool similar to that. One of our engineers built a "pre-ejb" tool that used Swing to connect instance variables to columns in a table, and generated all the code, including the tables, mappings, etc. He is modifying his tool to work with EJB 1.1 right now so that we may use it to manage all of our EJBs and not deal with all the inner workings. -Original Message- From: Jeff Schnitzer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 9:31 AM To: Orion-Interest Subject: RE: Why Entity EJBs? I also am questioning entity beans, after 5 months of intensive development with them. If you run Hypersonic in server mode and watch the sql output to the console, it should be readily apparent why... CMP produces *WAY* too many queries for fine-grained entity beans. The biggest problem is finder methods. Since all beans are lazy-loaded, iterating through the finder results of 1000 beans will produce 1001 SQL calls. There isn't any reason specwise that beans cannot be eager-loaded, but few (if any) appservers seem to support this. Does anyone know if there is any support for eager-loading of finder results in Orion? There doesn't appear to be from the documentation. I'm really disappointed in the entity bean concept. CMP should give us faster development times, faster code (with caching), and database independence, but at the moment we get *none* of the above. By stating in the blueprints that entity beans should only model course-grained objects and _not_ "one row of the table" they are effectively saying DO NOT USE CMP, because what is a CMP bean if not one row of a table? I noticed that most of the new J2EE patterns Sun recently posted are aimed at BMP. Sun's schizophrenia on this really pisses me off; with one face they like to show off entity beans and CMP because MS doesn't have it, with another they tell us to go back to the bronze age of handwritten SQL because the technology doesn't work. Gr. Jeff -Original Message- From: Dan North [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 20, 2001 4:41 AM To: Orion-Interest Subject: Fwd: Why Entity EJBs? Hi Johan. two-pence-worth I've been developing EJBs in a very (a) intensive and (b) short development cycle for about 5 months now. I've found that my methodology has leant towards what the JRF guys are talking about, but in a less formal way. From the backend forwards: I tend to use entity beans for storing/retrieving and most manipulation of data - ie. I have quite "fat" beans rather than just purely getters and setters. I then use session beans for workflow that doesn't seem to belong with any particular single bean, such as generating reports or anything that requires a few home interfaces' finders. I also use session beans for their transactional integrity when populating new beans from an HTML (JSP) form, especially when several beans will be created from a single form's contents and I want the whole lot to be atomic. We tend to use JSP and regular form beans for most of the other workflow stuff, and sometimes we'll have quite complex finder methods in the EJBs that join across several tables. The benefits to EJBs, and specifically orion, for me are: - Database independence: we're deploying on MS SQL Server but it's trivial to deploy to eg. Oracle for scalability or Hypersonic for local testing. - Network independence: I need to change no code to cluster orion on several hosts and also to split its responsibilities between being a web server on one host talking to another orion instance being an app server on another host. - Speed of development: I don't have to worry about how or where my data is being stored - I have orion's _fantastic_ OR mapping to do that for me. It seems to me that the JRF is taking the "best practice" approach, which is a fine and noble thing to do, but then overcomplicating the issue by wandering off into its own specification. All my SQL for each package is in one place (orion-ejb-jar.xml), and I don't have to worry about scalability or portability. If it says J2EE on the box, it'll usually have J2EE in the box. (Apart from the usual niggles with app servers being behind spec - again orion is pretty good for being up-to-date in this regard.) So I have all the benefits of JRF but with the backing of a technology as widely-adopted as J2EE. /two-pence-worth Disclaimer: I don't work for orion, I just love their product. And J2EE has been th
