> Mostly I don't take Arkins arguments that seriously because he cares
> about one thing only: performance. And his rhethoric is similar to the
> age-old "if I do it in assembler it will work much faster". In one sense
> he is correct; going to JDBC will produce faster results in some
> scenarios, however, using EntityBeans may be much faster in some cases
> since one can use caching heavily. Look at Javlin. Look at TOPLink.
Effective multinode object caching means $30-60.000 per CPU servers.
So performance with EJB entity beans is not for the common project, I think.
> They perform very optimized database access, and it is all transparent to
the
> bean developer if one uses EntityBeans. In almost all computing the best
> software is based on the restrictions that are imposed. If you say "hey,
> here's a technology that let's you do anything" I usually think "wow,
> yet another programming language..great..". Once you start imposing
> restrictions it lets you do optimizations, because the whole philosophy
> of optimization relies on the ability to make restrictions in what can
> be done. This applies on EntityBeans as well as other technologies. Now,
> since we have imposed some restrictions by using EntityBeans we may not
> be able to solve all scenarios, but we will be able to solve many of
> them quite well. And it also depends heavily on how clever your
> particular implementation is.
Current EJB 1.1 limitations means EJB is suitable for OLTP and not
many more scenarios. It is clearly not suitable for workflow,
asynchronous messaging, parallel processing, ...
<snip>The standard
> anti-EntityBean argument "well, what if you do a finder that returns
> 10.000 Entities" did not apply since we would never want to list that
> many incoming messages in the GUI. It would be silly from a GUI point of
> view. During the demo it all worked quite well and it never crashed.
Our systems use tables with 100k-1M records. We must deal with
paging for sure.
> Ah, and here's a killer. What do you need most: performance or uptime?
> Ask any online e-business and they would reply "both!", but in the end
> it is uptime that counts. Performance can always be addressed by
> clustering. And how do you get good up-time?
> 1) Don't write code. nr of bugs rises linearly (exponentially?) with nr
> of lines. KISS. Always.
> 2) If you have to code, don't write complex code, as it tends to be more
> buggy.
>
> JDBC coding breaks both 1 and 2. Which breaks uptime, no matter how many
> cluster-nodes you have: they will all break on buggy code.
We use several mechanisms to keep SQL out of our Java classes.
No need to use CMP entity beans to get SQL-less Java.
For example an XML file mapping Java classes and fields to
DB tables and columns, including lookup tables, 1..N relationships,
search criteria, etc. Very fast development achieved. Just get an XML parser
and develop a simple O/R mapper.
Best regards
Javier B.
www.tid.es
===========================================================================
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".
