> > CMP. It's a pipe dream of the EJB spec writers that not having
> > to know your data and how to optimally access it (writing good
> > sql) is some how possible. Remember these ideas were brought
> > to you from the same bunch that think forced serialized calls
> > into a bean is from a whole system design perspective a good
> > idea. :))
>
> If this is really what you think of EJB it is difficult to
> see why you bother
> with this mailing list - server-side applications are not
> simply multithreaded
> fat-client applications on a bigger box.
Reentrant beans causing fat clients an need for bigger box???
Non-rentrant beans makes for thin clients and small boxes??? LOL
Look again, serialized calls into non-rentrant beans is one of the
causes for EJB being low performing, RAM and CPU consuming when
compared to the benefits to reentrant beans and fewer objects handling
more client calls more efficiently. The complexity in the container
to track reentrant calls from same client, different thread etc etc
must bloat out the container, IMHO.
>From a robustness and code completness perspective; this is where
you need to move from simplistic example code to production code
that works even when 10k customers have hit your site:
- Client calls on an EJBObject must catch vendor specific exceptions
when the container has created the max number of beans in the pool
and vendors like Weblogic throw an execption back to the client
due to peak demand exceeded the container's pool size tuning.
When your container can't handle another method call on the bean,
what does the client do?? Loop 3 times on the bean.method() call????
You tell me?
Why not queue method calls?
Why not offer a quality of service property that you queue for this
time then time out...
- Or why not just put back the RAM efficiency
into the server side, remove the complexity from the client side
and support the corba'esk / RMI service dispatcher'esk mode of sharing
a single instance of an object for all method dispatches???
<robustness commercial code issue>
- When you look at the whole system design, the code that now is pushed
onto the client designer for mission critical, serialized calls into
beans has many side effects that some how this list has not adequately
discussed, IMHO.
</robustness commercial code issue>
> The problem with dismissing OR and CMP so comprehensively is
> that without them
> (or something like them) you can too easily finish up writing
> monolithic
> procedural COBOL/CICS-like.
Hmm? :)
curt
Curt Smith
Z-Tel
email: [EMAIL PROTECTED]
work: 404-237-1166 x182
FAX: 404-237-1167
===========================================================================
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".
