Tyler Jewell on Unlocking the True Power of Entity EJBs

Discussions

News: Tyler Jewell on Unlocking the True Power of Entity EJBs

  1. In his latest article, Tyler Jewell discusses Entity bean performance. He steps up to the plate and says: "The time has come for entity EJBs to have a spokesperson that will champion their vision, potential, and true power to the world."

    Read the article at http://www.onjava.com/pub/a/onjava/2001/12/19/eejbs.html

    Watch the Tyler Jewell video interview on TheServerSide.com.

    Performance this
    Performance that,
    I think my EJB
    Is a tiny bit flat!

    Threaded Messages (39)

  2. Jewell states: "But there isn't a single study that leverages entity EJBs using the "develop-once, deploy n-times" model. A system using entity EJBs following this model will have greater overall performance, robustness, and reliability than a SLSB with multiple JDBC operations."

    The article would carry much more weight, if it actually supplied some numbers to support this statement. If you're going to make statements of this kind, why not go all the way and do the study to back up your argument? Are we to believe this on faith alone?
  3. The study is already underway and I'll have quantitative proof points to show. But, the real point of the article is to create awareness and debate around the methodology & approach which no one has really advocated too much.

    I've written a number of articles and have always been very careful in my analyses. This will be no different.

  4. IMO, some points in the article appear to be questionable.

    For example,
    1) Usage pattern: Read data for display
    Usually, there are at least two (2) types of reads in any system, (a) reads that return sets of data and (b) reads that return individual records. For (a) reads, EBs are not useful, this type of read will be better modeled using SLSB with JDBC/JDO/whatever.

    For (b) reads, you may or may not occasionally hit cache. IMO, it’s difficult to justify the additional effort of developing RO and RW EBs, dealing with synch issues (some of the synch features may not be present in other app servers) and etc just for the sake of occasional cache hit. Even if the cache hit ratio is high, additional complexity, development effort and synch overhead will greatly reduce the benefit.

    2) Usage pattern: Batch update data
    <quote>
      <finders-load-bean> set to false, Required transaction
      demarcation, and only invoking setXXX(...) methods of
      EJBs. This will cause a findXXX(...) method to return a
      Collection of primary keys (PKs), but no data will be
      loaded into cache. A client can iterate through the
      Collection, modifying fields by calling individual
      setXXX(...) methods. When the transaction is committed,
      only the optimized fields of all of the PKs will be
      written to the database.
    </quote>

    I'm sure that this approach will be outperformed by ratio of 10x, if not more, comparing to SLSB+JDBC (or whatever) that simply runs an SQL update statement.

    Thanks
  5. Hi. I don't want the thread to shy away from the major point of the article:

    That in the long run of a development project, the EB model is going to reduce the amount of coding and produce equivalent performance for the whole system.

    Let's not look at the technology that exists today, because we can all find a number of situations where a properly coded SLSB + JDBC is going to be faster than the container.

    The contention is that app server vendors are free to give containers amazing flexibility that is altered by deployment that cannot be achieved with SLSB + JDBC.

    Let's make the assumption that at the core of a container, the container has the knowledge to create a perfect query each time. (Granted, this probably isn't done wholly today, but they will get there in the very near future). Meaning, that the query created by the container would be the EXACT same query that you would have created had you done JDBC directly.

    On an individual request, the container will be slower than the JDBC model because the container has overhead, TXs, security, relationship checks, and parsing of returned data into relevant objects. But, all of these things combined don't make the container that much slower.

    So, in these invidual cases, the argument is that a slightly slower request + less coding is more compelling than SLSB + JDBC.

    I think the real power of entity EJBs comes when you take the above statement and then start factoring in clustered containers with caches and the performance gains that they offer. Whether the caches is transactional or read-mostly is irrelevant because this model assumes that the application developer will have all of these caches available and they just have to choose the right one.

    In this situation, SLSB + JDBC is VERY DIFFICULT and can only be accomplished by the most seasoned architects. But, a quality container can handle this easily and opens up this range of capability to the developer masses. And, if used appropriately, significant performance gains will be seen.

    This could be an interesting debate because there are so many issues to consider.

    Tyler

     
  6. I wish I could agree with you but from my experience things are not that simple.

    <quote>
    That in the long run of a development project, the EB model is going to reduce the amount of coding and produce equivalent performance for the whole system.
    </quote>

    This is arguable and needs to be proven. Suppose, one developed a part of a system based on the "Batch update data" pattern just to discover that performance, provided by the pattern, is not satisfactory. One has to reimplement the functionality using a pattern that provides a better performance, e.g. SLSB+JDBC/JDO. In this example development effort roughly doubles.

    <quote>
    The contention is that app server vendors are free to give containers amazing flexibility that is altered by deployment that cannot be achieved with SLSB + JDBC.
    </quote>

    This is only partially true. One could also say that EJB 2.0 spec is not rich and flexible enough to provide the level of flexebility that can be achived with SLSB+JDBC/whatever. EJB-QL is not a rich language. Unless an app is very simple, one will have to use complex quieries or stored procs that cannot be achinve using EJB-QL(yes, it&#8217;s possible not to use SPs to but usually the alternative is pretty ugly).

    <quote>
    I think the real power of entity EJBs comes when you take the above statement and then start factoring in clustered containers with caches and the performance gains that they offer.
    </quote>

    There are many questions here. Performance of EBs in clustered environment has a BIG question mark, at least in my mind. Also, if you are sending a multicast message to other servers to synch the cache, how do you know that they got the message and were able to process it?

    Thanks
  7. Tyler,

    Its great that your article could open the eyes of some people to the power of CMP Entity Beans. I consider myself probably one of the first architects to design and build a large scale system using CMP technology way back in June-Dec 1999 with an aplha release of Borland AppServer 4. This is documented in J2EE in Practice. To this day the demo of CORE (the system built) is still one of the most impressive J2EE applications to show to customers in terms of performance. I built this system on my own within 4 months, after we lost the entire development team, something I could not have dreamed of in my CORBA days. A similar system was attempted by a well known telecoms solution provider and it took them 12 months with 6 guys using MS technology.

    I wish that the article could have come sooner especially considering that BEA and IBM for a long time have preached to customers (some of them my own) the stateless session bean approach.

    This is a nice change in direction and I believe was indicated by Cedric early on in the year on the EJB-Interest list. Of course in the early days the blame was on the spec now you say, in 2001, well its not the spec but the implementation, ;-). Please note that even with EJB 1.1 its was possible to implement many of the features provided by a EJB 2.0 CMP solution. Borland did it long before anybody else and its ECperf results testify to this.

    William
  8. I must say that often the critics come from people who haven't tried EJB 2.0 CMP.

    It does work, it does scale (at least TX_READ_UNCOMMITED), and it is really productive using tools such as EJBGen (http://www.jyperion.org/j2ee/ejbgen/article.htm) or Xdoclet.

    Obviously EJB CMP is not the solution for everything.

    But CMP is one great technology that allows companies to leverage their investment: they can focus on the business code and delegate the persistence code to the container.

    Moreover, without changing a single line of code, you can migrate to the next version of the container and automatically take advantage of its performance improvements.

    Too many people burnt their wings using CMP in the previous EJB Spec (1.1).

    Now, my best advice would be: try EJB 2.0 CMP, and you'll almost never think again about using SLSB and JDBC.

    Regards,

    Thierry
    www.janaudy.com
  9. William,

    I think what you say is the best example of "entities by experience": The ones who tried CMP with BAS seem to be lucky, the ones who tried it with other servers seem to be disappointed ;-)

    I'm fully with Tyler, CMP is something _really_ great, good 1.1 implementations (Borland, you know ;-) even made it a joy to work with 1.1 CMP, but it will even get better with 2.0.

    Someone stated that performance for "multi-record-statements" is very bad... in case you _really_ need it you can use an entity-bean ejbHome method.

    Someojne else asked whether the appserver could select three rows of a atble with many rows... it can exactly do this, you can group fields and mark them for eager or lazy loading. Even better, if you discover usage of the data is not as you predicted it (I know, this never happens ;-) you can very fast change it.
    I think we will even see (hoepfully in the near future, but I don't think so) some "learning mode" in the appservers which dynamically optimizes the loading mechanisms and groups the fields based on _real world_ usage.

    Exactly as Tyler said, the great advantage of CMP is the appserver (at least in theory) always (at least more often than hardcoded queries) knows the _best_ query to use.

    kind regards,

    Messi
  10. Hi, William

    Is there a case study / article / book that describes the system that you mention?

    Thanks!
  11. Tiberiu,

    You can find the case study online at:
    http://java.sun.com/j2ee/inpractice/attcase.html

    The case study is a part of the book: "J2EE Technology in Practice" (Addison-Wesley).

    -krish
  12. Hi William,

    We too did a CMP EJB 1.1 application in Dec '99; ours was on an early Weblogic beta, which I am _certain_ was loads more fun than you had (I think they had just discovered XML deployment descriptors) <ROFL>.

    The amazing thing was that once we designed the data, we had two junior guys who had never coded JDBC or EJBs that built (in our J2EE IDE) 60 CMP EJBs and the various session beans that provided facade, handler etc. patterns to them. Did I mention that they did it in like two weeks?

    If the tools would ever catch up with the specs, CMP EJBs (and JDO for that matter) could be quite potent.

    Peace,

    Cameron.
  13. Cameron Purdy wrote:

    <quote>
    The amazing thing was that once we designed the data, we had two junior guys who had never coded JDBC or EJBs that built (in our J2EE IDE) 60 CMP EJBs and the various session beans that provided facade, handler etc. patterns to them. Did I mention that they did it in like two weeks?
    </quote>

    It's nice to see that you did not loose your sense of humor and, besides Java code, you write pretty good fiction. For true dramatic effect I would say that two junior dudes never wrote any code whatsoever, in any language. And, yes, they did it in two days!

    Peace
  14. One Way: "It's nice to see that you did not loose your sense of humor and, besides Java code, you write pretty good fiction. For true dramatic effect I would say that two junior dudes never wrote any code whatsoever, in any language. And, yes, they did it in two days!"

    Actually, the amount of "code" that they had to write was minimal. The deployment descriptors (including the Weblogic specific ones) were automatically created by the IDE based on the bean design. The packaging (JAR/WAR/EAR) was automatic too. Most of the work was in creating the various databound properties (again, no coding, but lots of clicking).

    Peace,

    Cameron.
  15. Hi All,
    I understand the article bases its arguments on container optimizations. I don't believe CMP Entity will never take off. As all the best practices now state, entity beans are designed to represent coarse-grained objects, not single rows of a database. I strongly agree with this vision and I don't believe a corse-grained entity bean can let just the container manage persistence.

    Stefano
  16. Tyler: I agree 100% that entity beans greatly reduce the amount of code you need to write, and increases the portability. I <i>disagree</i> that it increases performance. In fact, I'd venture that it does the opposite. I have never seen a case where making something more loosely-coupled (and more portable) did not decrease the performance at least a little. That is fine with me, I think the advantages of loosely-coupled code greatly outweight the performance loss.

    I understand what you're talking about with not always using transactions, etc. when only doing read-only functions, and yes that will increase performance. <b>BUT</b>, as your article itself states, that is done in a <i>session bean</i> not an entity bean! So I fail to see how entity beans in any way increase performance as you claim.
  17. Entity Beans vs the rest[ Go to top ]

    Hi all,

    Performance is not the only yardstick by which enterprise applications are measured. Often just as important (or more important!) are metrics such as:
     - Complexity (How hard is the system to build?)
     - Modularity (Reuse?)
     - Extensibility (How easy is to enhance the system?)
     - Longevity (What is the usable lifetime of the App?)

    Although it is possible for a program using JDBC to outperform CMP Entity Beans, you have probably traded off raw performance for modularity and extensibility.

    But the speed benefits of raw JDBC can be elusive. There are a great number of optimizations that can be made on the CMP version of the application that cannot be made on the equivalent JDBC version.

    This is due to the fact that the EJB Container has a great deal of control over how to execute the CMP code, but has almost control over raw JDBC. So, for example, the CMP engine can reorder the data access to the database to trade off latency for throughput, and thereby scale the system further. Or, the Container can trade off time for space, by using algorithms that either use more memory, but less CPU time, or vice versa. And while these same optimizations are possible for the direct JDBC code, this requires code changes to your application. In the CMP case, it is the AppServer that is being configured and optimized, not your code.

    Also, for example, the EJB Container can run as many instances of entity beans as there are simultaneous clients (actually simulataneous transactions) and these instances can run in parallel servicing requests faster. Such an approach will ensure that your enterprise application remains scalable. Again, the speed benefits of raw JDBC can be elusive. You might see gains in speed when using raw JDBC on a small number of simultaneous clients which is typically how tests are done. A developer simulates two or three or 10 simultaneous clients with raw JDBC, tries the same with a CMP equivalent and concludes that raw JDBC is faster. But how does this system scale and perform when using 100s or 1000s of simultaneous users?

    <aside>
    But its nice to see BEA do an about turn and now advocate the use of entity beans. We've been saying the same since the beginning - it is wrong to blame the EJB Specification for the poor performance of a product. And I guess runs with ECperf will prove the same as well. For example, we've seen gains of over 100% when using CMP over BMP. BMP - in the words of our AppServer architect - is "an abyssmal compromise" and in my personal opinion only one rung below session beans coded with raw JDBC.
    </aside>

    -krish
    (Borland)
  18. For me, this article suddenly opened my eyes to the possibilities inherent in Entity Beans. The idea of deploying the same bean optimised for different data scenarios is so obvious that I can't believed that I missed it all this time. Thanks for the insight, Tyler. You rock.
  19. Hi Tyler,

    I have a few questions:

    How could the container anticipate the situation where one only needs to fetch three colums from a twenty column table? Can the application server be smart enough to select just the three. If the result set is large, there can be great gains if the App Server can determin this.

    I see the coding effort reduced, however the deployment process is increased. One mans benefit is another mans headache. Applying security to a great number of Entity Beans could be a maintenance nightmare. Especially if security is maintained by some security standard inside a company. The coder may not need the architectual skills, but the deployer will need them. A data model change that requires a code change, lets say to the condition, is just filtered to the deployment descriptor where the deployer needs to redeploy.

    Couldn't I create four different objects for insert, update, delete, and select and append where clauses to them as I see fit. Then the application can provide a different session interface for differnt transaction senerios?

    I understand caching could be an issue, but most web applications are one time requests. Leaving data cached in-between web requests is dangerous? I see the potential with Entity Beans, however basically, I feel if I go the entity route, I am saying all applications that need access to my data has to do it through and only through my application servers. Many customers are not ready to make that commitment, especially if legacy applications still exist. Selling this to a DBA has always been an obstacle for me.

    Locking in a clustered environment just filters the wait from the database to the application server. It may help the database resources and spread things out, but someone has to wait?

    Making easier for the initial coding effor I beleive has been achieved. Its the code and depoloyment maintainers and production support people that get screwed.
  20. Design decisions very much depends upon the functional and non-functional requirements of the project. The issues of performance, reliability, scalability and reusability depend upon the non-functional requirement of the client. If you need a scalable and maintainable, good object oriented design; go with the entity beans and harness their full power (I m with Tyler). However if performance is your ultimate goal, time is not enough + your developers are not comfortable with object oriented paradigm; you have little options but to use stateless bean and jdbc.
    I am only saying here is that decide about Entity or Stateless keeping in mind the dynamics of the project. Stateless beans using JDBC surely increase the performance but at the cost of neat and clean design (as Tyler suggesting).
    In my last project client rest the design decision with me and I went with a session facade with both CMP and BMP model (offcourse depending upon the problem complexity and use case).
    But my current client needs performance; time is less and scalability is a requirement for the project which is a huge marketplace. I will share the design decision with you ppl as we finalize it.

    Regards
    Open for any comments
    Shoaib
  21. Reading this thread I got a feeling that not many people are aware of the full power of EJB 2.0 CMP beans. The app server vendors need to do a better job in providing advanced examples to demonstrate how read-only and read-mostly beans are done, and how to configure lazy loading. Also to the gurus out there, instead of publishing patterns that are work-arounds for EJB 1.1 entity beans limitations, why don't you provide more examples of how EJB 2.0 solves those problems?
  22. Very nice article. It was a pleasure to read.

    I think the idea is very useful, and I look forward to trying it out.

    But it seems to me that Tyler doesn't quite go far enough. Two entity beans that use the same java code but different deployment descriptors are really two different entity beans. So why not change the java code as well? You can use one relational schema and N object models that are optimized for different access patterns. Then you can *really* tune your application(s).

    As far as performance goes, the solution to the problem lies in distributed caching. There are distributed caches out there, but I think there is still a lot of work to be done in this area.

    I can think of one practical solution: use Oracle's "real application clusters", or (better) DB2 on a parallel sysplex cluster. Set up an instance of the database for each instance of the application server, and let the database handle the concurrency control. Obviously this is an expensive solution, both because the database license fees will be very high, and because of hardware costs. With that kind of setup the power of entity beans will become apparent :)

    Guglielmo

  23. Cardinal Sin of Entity Bean Misuse[ Go to top ]

    I've been in two companies that have used the wrong transactional attribute on session-facade-to-entity-bean architecture and suffer badly on performance; a single DTD tag change increase performance 4x or more! Here's the scenario:

    SSB facade (NotRequired) -> EntityBean (Required) getA() + getB() + getC() + getD()

    If you have a SSB method that simply finds an entity bean and retrieve info from all its fields, inituitively you'd set this method's CMT attribuite to NotRequire since ReadOnly requests SHOULD NOT require transactional overhead. What many people don't realize is this forces the container to refresh the entity bean from the db for EACH getter call, resulting in 4 pairs of ejbLoad/Store in the above example to retrieve fields A, B, C and D. By turning the SSB method to Required, only one set of ejbLoad/Store is called for the entire transactional context. Furthermore, leveraging a vendor's "dirty-data" recognition feature will shed the ejbStore.

    I have seen this mistake committed in two companies by otherwise brilliant architects, simply because this type of transactional management is NOT INTUITIVE! However, few developers/deployers realize misuse of CMT will seriously undermine the data caching capability of the container, whether you're using CMP or BMP. I think this is one of the primary reasons why people complain entity beans are slow, and needs to be brought to attention by those who advocate entity beans.

    Gene
  24. Cardinal Sin of Entity Bean Misuse[ Go to top ]

    Gene,

    This is one of the many reason why I created JDBInsight. I cannot understand how developers can build systems using EJB without something like my tool.

    I am very serious and not looking for a flood of purchase orders though I would not complain about it, ;-).

    I have tested JDBInsight with systems a year in production and founds bugs that had never come to light until now, both in the application code and cmp engine. The application code and descriptors is where the most damaging bugs can be found.

    William
  25. I am a newbie to J2EE. I am wondering about whether the success of EJB, Servlet and JSP will essentially wipeout the need for products like RV (from Tibco) and MQSeries.

    Having worked on RV and MQSeries (and just getting started on j2EE) I am getting convinced it is a matter of time before middleware products are done away with as we move to component architecture.

    Can someone explain where I am erring. Thanks
  26. "On an individual request, the container will be slower than the JDBC model because the container has overhead, TXs, security, relationship checks, and parsing of returned data into relevant objects. But, all of these things combined don't make the container that much slower. "

    Hi Tyler! I saw you here in Dallas recently; you're a great speaker, albeit obviously full of yourself just a tad :) with all due respect of course.

    Anyway, to reply to the article, man, I can't believe anyone is even debating this. Entity beans are so much slower than straight jdbc it isn't even funny. I'm mainly talking about bean-managed here. I mean, we're not talking marginally here, we're talking HUGE differences.

    I recently did a project and even tried using read-only caching strategy. Although that spead things up probably by 1/3, it still wasn't enough. This was a web app with response time being very important. What I wound up doing was coming up with an architecture where I extracted all the "read" features of the BMP ejbe's into a factory class that the ejb then used. By doing that, these read features were also accessible by other parts of the system where speed was paramount, but the other features of ejb were not a requirement. So, I had the best of both worlds; all that comes with ejb when I need it, and a more "leight weight" capaibilites as well. It seems to have worked out very well.

    It was amazing to see the difference side-by-side of straight servlet+jdbc and bmp ejbe's. I couldn't believe it. And even with straight jdbc, as long as you're using an app server, you still have access to all the cool stuff that the app server gives you. Really what entity beans mainly give you is quicker development time, but imho, not that much once you come up with the initial groundwork for database access. And certainly, they aren't worth the price you have to pay!
  27. <quote>
    It was amazing to see the difference side-by-side of straight servlet+jdbc and bmp ejbe's.
    </quote>

    Tracy, did you try a similar comparison with CMP 2.0?

    CMP has quite a few advantages over BMP in many cases (e.g. finders).

    --
    Cedric
  28. "Tracy, did you try a similar comparison with CMP 2.0?

    CMP has quite a few advantages over BMP in many cases (e.g. finders). "

    No, we're using wls 5.1
  29. Tracy Milburn said:
    "Really what entity beans mainly give you is quicker development time, but imho, not that much once you come up with the initial groundwork for database access. And certainly, they aren't worth the price you have to pay!"

    Entity Beans give you object transparency. That's where we are all trying to get. Performance, development speed, etc are important, yes, but are not the key issues. If they were Java wouldn't be in the picture.

    We do have to concern ourselves with real-world issues like performance and development time but we also need to keep our eye on the ball; that is, building OO systems. Servlet/JDBC, even stateless session beans are very not OO.
    Therefore, you get no advantages of object oriented techniques.

  30. "Entity Beans give you object transparency. That's where we are all trying to get. Performance, development speed, etc are important, yes, but are not the key issues. If they were Java wouldn't be in the picture.

    We do have to concern ourselves with real-world issues like performance and development time but we also need to keep our eye on the ball; that is, building OO systems. Servlet/JDBC, even stateless session beans are very not OO.
    Therefore, you get no advantages of object oriented techniques. "

    Excuse me? I think you're the one that has lost the ball; believe me, there were plenty of very good "OO techniques" LONG before Java came around, and certainly before ejb's. What makes entity beans more OO than anything else? Being OO has nothing to do with it. Reducing the code you have to write and delegating responsibility is what entity beans are about; please don't try and sell them as being "more object-oriented," that makes no sense.
  31. "What makes entity beans more OO than anything else?"

    From the client's perspective an entity bean looks like a local object; an object with state and methods.

    "...there were plenty of very good "OO techniques" LONG before Java came around, and certainly before ejb's."


    "Being OO has nothing to do with it. Reducing the code you have to write and delegating responsibility is what entity beans are about; please don't try and sell them as being "more object-oriented," that makes no sense."

    Why, then pray tell, are there entity beans? In your world session beans are all we need.
    Why has so much effort been put forth to build POAs in CORBA? How about DCOM? Object transparency is the answer.

    If you want to build data-centric systems, go ahead. You certainly can use an EJB container's services and provide the client data. I prefer to provide clients objects for the many, many, many benefits that objects provide.

  32. "From the client's perspective an entity bean looks like a local object; an object with state and methods. "

    And that has nothing to with with OO at all. That's all I was saying, don't tout entity beans as being OO, they're just components that's all.

    As for your question of why we have entity beans, imho, the idea is fantastic, esp. with cmp. The problem i have with cmp (pre 2.0) is they're very limited. I use bmp for almost everything, but on the idea that 80% of db access is read-only I've come up with an OO solution that factors out ALL database access from the entity bean and exposes it to other types of clients as well, not just those looking for a remote component. That's what scalability is about; I can use them for an app that is running on a machine that "houses" everything, or I can use the ejb interfaces and move everything around if need be. I have that choice this way, using this framework.

    So keep doing things the way you're doing them if that works for you. But again, don't try and sell ejb as being the same as oo. It's more accurate to say that ejb=component.
  33. "Every test case used on entity EJBs for performance doesn't factor in the relative weights of how the data will be accessed in production. For example, Web-based systems hardly access data in a read-write transactional manner, and are primarily read-only systems. Typical test cases would use read-write transactional entity EJBs to gauge the performance for all scenarios. Yuck!"

    Again, even using read-only entity ejb's, performance isn't even CLOSE. I've always been one to choose maintainability, flexibility etc. over coding for performance, but there are cases where the hit is just unacceptable. That's why I use a combination of bmp ejbe's and straight jdbc using factories; it gives you both capabilities whenever you need it. If you're doing only read-only operations, why the heck do you need transactions?
  34. Hi Tyler,

    Boy am I late to this thread! You certainly lit a fire here, which is great, and I guess a large part of the point.

    I enjoyed your article, and have a few comments:

    1.
    First of all, kudos to giving a lot of attention to the importance of data access Usage Patterns ... I consider it to be the number 1 J2EE design factor, but many don't think about it until halfway through development.

    2.
    One reason that SLSB-JDBC solutions are very popular right now, is (as you mention) because pre EJB 2.0 CMP was limited and container caching mechanisms were not very sophisticated.

    This being said, many software shops (mine one of them) have jumped through hoops to stay on the EB track (be it with BMP), by writing well-abstracted data access code.

    I spent a lot of time designing and writing a pretty sophisticated DAO layer, used by both BMP entity beans and also SLSB-JDBC beans (only two JDBC executeXXX calls in all code ... enables easy logging!). I'm sure it looks a lot like code in a lot of vendors' CMP implementations.

    Now there is no denying that CMP is catching up with this kind of optimized SQL. Furthermore there are caching strategies that can be performed with CMP that cannot with BMP, at least not with current hooks available. The question is, should I throw away my DAO now that I've already gone through the trouble to write it?

    My point is, I guess, that for the near future, many apps (especially web-based) will need SLSB-JDBC for some bulk read-only queries (and IMO all but most general stored procedures incur a development cost that significantly detracts from the benefit of CMP). If developers don't want to go nuts, they will write a nice DAO layer. And then they might say well, let's use that to get a really good BMP. And then they are in my boat. Just seems like something we are likely to still see until CMP performs well enough so people forget about that last step and can enjoy all the benefits you mention. And I agree, that day will come.

    3.
    As far as I know, WL is the only container that has invalidation methods for EBs, to support a Seppuku read-mostly, cluster-wide solution. For your plain vanilla app server, you have to resort to some trickery (see my post in Patterns). Of course, more power to BEA for forging ahead.

    Oh, and I am looking forward to this next article! Container optimization for data access is a very interesting topic.

    Lawrence
  35. Lawrence,

    You are mistaken. WebLogic was not the first to offer some of the cmp optimizations you talk about. For the record Borland AppServer 4.1 had these and much more way back in June 1999. When people where writing their own readonly detection code with the WL cmp engine which seems to defeat the point of using cmp.

    The Borland ECperf results published just recently which BEA and IBM have yet to produce shows that with CMP 1.1 you can achieve very good performance without the need to resort to using BMP and writing your own home grown persistence engine. Its worth pointing out that the ECperf results are based on BAS 4.5.1 nearly a year old (Borland Enterprise Server 5.0 has just come out) and the cmp engine has not changed that much since 1999.

    It would be nice for Tyler to give credit (kudos) where its due even it is not just Borlands implementation but some others who have tried to give customers what they need for sometime in the entity arena.

    William

    PS: I thinks its great the BEA has done an u-turn we will all benefit from this.
  36. Borland's ALWAYS been ahead of everyone in abilities, and behind in market share. That's too bad. I used "turbo c" and "turbo pascal" back in the old days of the pc nad nothing at the time could even come close to touching it. Then, micro$oft came along and... well the rest is history unfortunately, as was the case with many other fine products (note, although I feel for netscape I'm not considering the browser one of those 'find products' :)

    Take care
  37. Tracy,

    Maybe Ed Roman is right when he says that "unfortunately reality is that good technology rarely succeeds in the marketplace because it's good technology. Usually it's the technology with the best marketing that wins."

    Regards,

    William
  38. "Maybe Ed Roman is right when he says that "unfortunately reality is that good technology rarely succeeds in the marketplace because it's good technology. Usually it's the technology with the best marketing that wins."

    Well, I tink "rarely" is a bit strong, but if you take out the word rarely and substitue it for 'often' I would unfortunately be forced to agree...
  39. Hi Lawrence,

    "If developers don't want to go nuts, they will write a nice DAO layer. And then they might say well, let's use that to get a really good BMP"

    Exactly! That's my viewpoint as well. When I started working on this latest site, it came clear quickly that pure entity beans were not going to be acceptable. Like you, I abstracted all the sql out of them, exposing the "read-only" features to pure jdbc clients, a framework that the ejb itself also looks to to perform its same sql queries. Most database access is read-only. THis worked VERY well. The result is very scalable, still keeping the abilities of entity beans with the performance of pure jdbc.

    Great minds think alike...
  40. Can you advise me if you have Entity Bean which is meant to be read-only binded into the JNDI, how can you achieve concurrent access to this Entity Bean in a clustered environment? In EJB Spec, Container will handle multi-thread access issue via serialize the access to bean. So if you only have one instance of Entity Bean, the access to the bean is serialized anyway. Unless, the EJB container will break the rule for this specific DD? This sounds a little bit weird.

    IMHO, if you really have read only entity, model it as normal Java Bean using immutable pattern(like String) is still much more scalable solution in a real clustered environment.