>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.


the elephantwalker

Reply via email to