> The problem is that we end up with:
>
> client --> statefull session bean --> stateless session bean --> entitity
> beans --> database
>
> Each arrow is a remote invokation, with the overhead of network latency
and
> the marshaling and unmarshaling of data.
>
> May be I am missing something, but I can not see how a large system can be
> implemented like that. If your application server provides optimzation
> whereby co-located beans end up calling each other using local method
calls,
> then at least you solve the performance hit. YOu still have to deal with
the
> overhead of generating all these extra java files for each bean, even the
> dummiest and most passive one.
>
> Can anyboddy provide some useful insight on how to deal with this?
client --> stateful session bean -> database
Forget the entity beans. Use an O-R mapping tool in the stateful session
bean for your domain entities.
You're also forgetting in your budget analysis, the remote communication
substructure that is used for each bean. There's some ways to amortorize
this cost, but none of the methods are as fast, nor as lightweight as simply
using an O-R mapping tool to manipulate the "entities" in the database while
in a stateful session bean.
You can't beat the low overhead of this method, as doing nothing is
certainly always faster than doing something. Caching, pooling, and all
that fanciful stuff still costs. It's also complicated and ugly code that
sucks up resources. AND the entity implementation is undoubtedly using the
*same* or at least similar O-R mapping mechanism for the container managed
persistence.
You'd have to have a pretty darn good reason to give *every* one your
entities in the domain a communication/security/transactional identity.
"Because they are there and easy" is simply not a good enough reason, imho.
This is poor engineering - just my opinion.
Good reasons for entity beans include federation of databases, distributed
locations of the various application databases, wrapping of legacy systems,
etc.
===========================================================================
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".
