It seems that my (and, at least to some degree, Peter's) specific
problem is misunderstood.
In my case: the problem is NOT getting the data from the database fast
(the finders execute fast enough).
I think Jboss does not have a problem there, but that's my guess, as I
do not have personal experience
with other app servers.
The performance is lost, when I try to convert the a collection of local
entity bean references
into a collection of value objects. None of the previous posts (except
Peter's) touches upon this subject.
I want to understand and, if possible, solve this 'value object
conversion speed' problem:
Collection localBeanRefs = localHome.findBySomeCriterion(...); <--
This is not the problem (good job, Dain) !!
Collection valueObjects = new ArrayList();
// The following for-loop is way too slow.
for (Iterator beanIter = localBeanRefs; beanIter.hasNext();) {
LocalBean localBean = (LocalBean)beanIter.next();
ValueObject valueObject = ValueObjectFactory.createValueObject(); //
Same as new ValueObjectImpl();
valueObjects.add( localBean.buildValueObject( valueObject ) ); //
does: valueObject.setAttr1( getAttr1() ); ...
}
The same using JDBC:
ResultSet rows = myJDBCWrapper.executeQuery( query, dataSource ); <--
Needs same amount of time as finder above.
Collection valueObjects = new ArrayList();
// This is at least 3 times faster than the for-loop above.
while (rows.next()) {
ValueObject valueObject = ValueObjectFactory.createValueObject();
valueObject.buildFromRow( rows ); // valueObject.setAttr1(
rows.getString(...) ); etc.
valueObjects.add( valueObject );
}
The for-loop should be able to convert 1000 local entity bean references
per second or better for simple entity beans.
I am not interested in any CMP vs non-CMP debate. TSS may be a better
place for this.
It would be convenient, if the size of the result sets, that can be
handled using CMP, coincides with the number of rows
you should/could reasonably display in a dialog or page in your
(web-based) GUI. This would remove the need to switch
to raw JDBC, when doing the CMP equivalent of plain vanilla (for
instance) "select * from BeanTable where lastUpdate >= '10/20/2002'"
queries. That's all I hope for.
CMP will keep getting more powerful over time. Using it is 'Making the
trend work for you'.
Regards
Georg
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:jboss-user-admin@;lists.sourceforge.net] On Behalf Of Dain
Sundstrom
Sent: Wednesday, October 30, 2002 01:07
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] Entity Bean Performance Tuning Help
Emerson Cargnin - SICREDI Serviços wrote:
>
>
> Dain Sundstrom wrote:
>
>> Emerson,
>>
>> 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.
>
>
> what I really mean was that cmp would be alot more usable : )
>
> 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?
Yes, in 4.0 there will be an abstraction layer between the cmp view of
the world and the physical storage. This means that it will be possible
to map several cmp beans in different applications to the same store.
The real trick is keeping the caches in sync and this is where the new
invalidation code comes into play. Another change is will be the
introduction of a domain concept above applications. Applications in
the same domain will be able to share a common store manager. These big
architectural changes are designed to make this type of application
possible. (Note: all of these, except the invalidation code, are still
in the concept stage of development)
-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
