Hello Georg,
Do you mean that your slowness problem occurs when accessing the collection
*even* in mono-threaded behaviour? If I understand your scenario, you have
something like this:
- a web page that display the content of 4000 entity beans (either directly
or using a SLSB)
- the entity beans are loaded at once (no N+1 issue wrt data loading)
- everything occurs in a single transaction
- you hit the refresh page of your browser (i.e. only 1 access on the whole
system)
- you get really bad data at the synchronisation level. Right?
As what you describes seems to be an experiment, do you have a very small
example (EAR) that contains:
- the CMP that you use
- a servlet/JSP that uses direct JDBC call to retrieve this data (with a
time counter)
- a servlet/JSP that uses the CMP to retrieve the data (with a time
counter)
- this would be using the embedded HSQL DB
- a servlet/JSP that can be used to populate the DB with dummy values
Maybe, if we are lucky, you already have this small setup ready: would you
agree to send it?
cheers,
Sacha
> My problem is: Creating value objects through calling a method on an
> CMP2.0 entity bean takes 3 to 10 times more time than walking through an
> equivalent result set of a 'raw' JDBC query. I tried to dig into this
> issue by stripping down the interceptor stack !as an experiment! to the
> bare minimum. The result of this experiment was, that the
> EntitySynchronizationInterceptor is the only interceptor, that changes
> performance significantly in my setup. Removing the transaction or
> security interceptors did not have any significant impact.
>
> Getting the data from the database into the Jboss server memory is not
> the problem. The finder I am using for testing returns a result set with
> 1000 rows. It uses the default load group. This means that all data is
> in memory after the finder has completed, which takes only a few hundred
> milliseconds, just like issuing a "select * from BeanTable". For this
> reason playing around with page sizes and load groups etc. is pointless.
> My experience is that locking has no measurable effect on the
> performance (the performance test is strictly single-user).
>
> The time is lost when I walk through the collection of entity beans
> returned by the finder and call a method on each to create the value
> objects (one method call per value object). Others have come to the same
> conclusion, but I have not found a post that points to a solution of
> this problem.
>
> I really would like to be able to do a web page, that displays at most
> about 4000 rows, using entity beans and CMP2.0. But with the current
> performance I have to switch to direct JDBC calls in my stateless
> session beans every time I have to display more than 500 rows (Jboss
> 3.0.3 running on a dual UltraSparcIII with 4GB memory and an Oracle db
> on similar hardware).
-------------------------------------------------------
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
