Anne,
>As for entity beans and container-managed persistence -- there is no
>requirement in the specification that states that entity beans map to
>database rows. It's an implementation issue.
Finally, someone said it right! There is not much point in using multi-tier
architectures if the middle tiers only duplicate data available on the back
end.
>Persistence PowerTier,
>GemStone/J, Secant Extreme, and other implementations support much more
>complex mappings. WebSphere is definitely not to best performing app server
>on the market. (the next release due out in the next month or so should
>bring WebSphere a little closer to par with the other products out there).
We (Ejipt) are allowing developers to specify the exact SQL statement(s) for
CMP to execute. This provides the greatest control and flexibility over how
business components are mapped to data stored in the underlying database(s).
Using this approach, you can reliably construct your beans from data
residing in arbitrary tables (or even databases) in a very straightforward
manner.
>The above three implementations provide a shared object cache that allows
>you to cache the data in memory. It dramatically reduces the number of I/Os
>and offers much better data access performance.
I am surprised that you are pitching proprietary caching solutions to the
supposedly "write once, deploy anywhere" EJB component architecture. In my
experience, entity beans provide the necessary standard and scalable
framework for caching/sharing server-side data efficiently without having to
step out of the EJB programming paradigm.
Imre Kifor
Valto Systems
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
