Dain Sundstrom wrote:
Emerson,what I really mean was that cmp would be alot more usable : )
I disagree with you classification that cmp is not usable. There are many people that find the performance completely with in their expectations. It is only when you have a high expectation and a very complex schema that you have problems.
by the way, we are in in a doubt about a point of architecture :
as i discussed before somew time ago, in a very big system (like the financial one i'm on) there is the need to separate the modules of it, like one for accounting, other for savings, etc. And each one would need to talk with a couple of others. The problem : to separate and allowing those to be separate deployable, you would have to get rid of cmr's and make the modules talk with each other through session facades. In this case even with cmr read-ahead would do nothing to avoid the n*cmr needed to access each entity. And worse, how could I manage the constraints between 2 related (and module separated) entities? one would need to consult the dependent module (via session facade) to see if it could be deleted...
I don't know what going be the solution, throwing entities away, or making up a monolitic system using cmr.
any suggestions?
is there anyone that modeled a very big system using CMP/CMR?? how to isolate and decouple the sub-systems, isn't it what we've learned from Software Engineering classes? and and we are at a point in the construction and having a defined arquitecture that is almost impossible go back (or at least it would be a lot of waste of time).
May applications happily use CMP today, and these applications will benefit from the work that we put into the cmp engine on a daily basis. The applications that don't use CMP can only get benefits from what they can program by them selves. As I said it comes down to a trade off.
Also, I truly believe that the Jboss persistence engine will be able to be on par with any custom code using a simple CMP 2 interface, because we will allow you to plug in your optimized code. The best of both worlds.
-dain
Emerson Cargnin - SICREDI Serviços wrote:
i think that maybe using a read-ahead configuration for cmr could turn CMP usable, hence the cause of the slowness (IMHO) is the great number of selects as you navigate through each BEAN.
Jason Westra wrote:
Dain wrote:This was my point. Sounds like you agree. :) The current CMP design hasI disagree with you here. It depends on the type of reads you are
doing. A lot of applications increase performance by offloading
processing to the database with very complex queries and stored
procedures, and the current CMP design can not benefit from this design.
problems with large, complex reads. You can't effectivly use CMP for
everything, nor was the EJB spec's CMP section able solve ALL data query
problems.
J
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net]On Behalf Of Dain
Sundstrom
Sent: Tuesday, October 29, 2002 11:43 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Jason Westra wrote:
Hi JBoss friends,
I tend to agree with Bill and Dain's last posting here. There are certain
things that CMP is not designed to do *well* and large, heavy reads is one
of them.
I disagree with you here. It depends on the type of reads you are doing. A lot of applications increase performance by offloading processing to the database with very complex queries and stored procedures, and the current CMP design can not benefit from this design. The JBoss 4.0 design will be able to benefit from hand tuned queries.I'd venture to guess the same performance problem will occur on other app
servers, in which case, it is not a war of servers, but a principle of
application design (SSB+JDBC vs. CMP). If the numbers come in much better
from testing on other app servers, we need to get JBoss "fixed". Until
then,I'd recommend a different approach than CMP.My goal for the 4.0 architecture is to enable the easy use of a hybrid approach to CMP. In this design you can use CMP for the 98% of you app that performs well under the current code and for the 2% that needs hand code you can plug in a custom interceptor to tune queries. -dain ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
-- xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Emerson Cargnin | | Analista de Sistemas Sr. | | Tel : (051) 3358-4959 | | SICREDI Serviços | | Porto Alegre - Brasil | |xxxxxxxxxxxxxxxxxxxxxxxxxx| ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
