>Entity bean caching I have found to be remarkably useless. First of >all, it depends on a pessimistic locking strategy, which is both hard to >use (gotta love those deadlock exceptions!) and not applicable to a >clustered environment or any environment in which the database table can >be modified from an external source. Furthermore, finder methods are >not cached - and with an eager loading strategy, I really have to wonder >what the great advantage of the caching is... bringing all the bean data >back usually isn't that much more expensive than bringing just the PK >data back, and if it is (because of large data fields) then your cache >is going to have size problems anyways.
The latest oc4j release has four different load-locking strategies to choose from, and you can be sure these will make it into Orion. pessimistic, old-pessimistic, optimistic, and read-only. There are also stategies for timing out instances for ejb's. >Irrespective of who may be a smarter developer, I can guarantee you that >I know a *lot* more about *my* specific business logic than Karl or >Magnus. Furthermore, Karl and Magnus are for the most part just >implementing a specification produced by a committee of labcoats >dedicated to a lowest-common-denominator set of features that IBM, BEA, >Borland, Sybase, & the rest of the implementers can agree to. The >absence of ORDER BY in EJB-QL and the lack of a standard PK generation >mechanism make me seriously wonder if any of the people writing the EJB >spec have ever used it to implement a real-world application. I believe they are also on some of these committees. They have also implemented a far better finder language than ejb-ql, and you can use ORDER BY in the orion-ejb-jar.xml. Brett McLaughlin has published a truely excellent strategy for producing pk's. Go to flashline.com to see Brett's column on this. regards, the elephantwalker www.elephantwalker.com
