-----Original Message-----
From: THS [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 07, 2000 4:51 PM
To: 'A mailing list for Enterprise JavaBeans development'
Subject: RE: About Entity Beans crisis and more...
If I use a finder that returns more than 1 row example, Enumeration e =
FooCMHome.findBySubscriptionID(subID) , then ejbLoad() will be called for
each instance or row and then called again when a method is called.
Conversely if I use finder as follows, fooCM =
userLoginCMHome.findByPrimaryKey(pk) ; then ejbLoad() is not called until I
call a method on that bean. Can anyone explain the difference! Thanks in
advance. Trying to grapple with performance tuning/issues. In the first
case ejbLoad() is being called twice for a record/bean.
Toni
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]] On Behalf Of Thibault Cuvillier
Sent: Thursday, December 07, 2000 3:50 PM
To: [EMAIL PROTECTED]
Subject: Re: About Entity Beans crisis and more...
>Francesco Marchioni wrote:
>> I've read carefully the posts concerning entity beans
>> performance issue. I made up my mind that it's a waste
>> of resources to use ejbFind methods in Entity Beans
>> because this will cause an useless trip to ejbLoad and
>> ejbStore methods (if I have understood correctly).....
>
>This is (somewhat) incorrect. If you only do find there should be no
>ejbLoad and ejbStore. There is no need to activate on finder, although
>it *is* a valid container implementation option. However, I think that
>those who *do* activate on find have a flag to turn that off.
Yes, but this happen only if you call findXXX and don't use the result
!!!!!!
Is a normal query, you call findXX and browse the content, and each entity
will
be loaded independently. Even if you can optimize when the ejbLoad/ejbStore
are called on some servers using non-standard server features, the
performace overhead is HUGE.
1-- Do you really need to distribute data?
I always design the business worflow using regular Java classes, using EJB
entity as a surrogate (bridge design pattern), only when it's required by
the application requirements (need long-lives locks, shared data with state
change notification...). In fact the need to distribute data is not frequent
on projects because the web container create service level interfaces which
are in charge of controling the transaction boundaries.
With this design, persistence can be implemented by using an O/R mapping
tool if you need a cache, or by JDBC.
This design create a stateless middle-tier:
* which scale up
* which is based on a clear and maintainable OO design.
* which can use efficiently load balancing
2-- Distribution mythology
Object distribution is a MYTH because of the network constraints.
Distributed OO design use OO paradigm to distribute services which is
totally different than distributing data.
The middle tier be design as a statefull server to:
* add an object cache to solve performace problems coming from the O/R
mapping layer
* manage collaborative objects (which notify state change to the clients)
Keeping the state of the data on the server may dramatically impact the
performance on a cluster of servers.
3-- You can develop a consistent OO model without using entities
The non-EJB data are transfered to the clients using StateHolder to keep a
consistent OO view on the data.
Conclusion
----------
EJB entities mixed up 2 problems: distribution and O/R mapping. What I need
on my applications is a simple way to generate an object binding to my
RDBMS. I don't need to create a distributed interfaces at the data level.
Most of the j2ee applications are in this situation. I strongly beleive that
the J2ee spec needs to make a clear separation between this 2 issues. A
tight integration of EJB and JDO may be a solution.
My 2 cents,
Tibo
http://www.valtech.com
Project delivery with skill transfer, Mentoring, Education
===========================================================================
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".
===========================================================================
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".
