Accessing CMP 2.0 entity beans: very slow

[morphace]

Hi,

I'm currently running 3.0.0beta2 Date:200203180716 togehter with Oracle 9i.

Excuting a query on a entity bean and retrieving the bean instances takes a looooong time.

I executed a query, which returns about 60 bean instances. I takes about 5 seconds!

The query itself takes only about 55 millisecons.

I retrieve the bean instances in a loop. Accessing only the primary key works fine (evidently) :-).

When I retrieve the first non primary key attribute it gets slow :-(.

JBoss and oracle are running on the same machine (SuSE 7.2 Linux, Athlon 1GHz, 1GB RAM).

Executing a similar query directly via JDBC is fast.

Any ideas ?

[dsundstrom]

Are you doing this in a single transaction? My guess is you are not, and you are using read-ahead on-load, which is the default. In this scenario you load a whole bunch of data for the next n beans and then you end the transaction, and all of this data is discarded.

Take a close look at the server.log file. Are there excessive queries?

[morphace]

Hi Dain,

yes I'm using read-ahead on-load, because I need all the instances, which then are transported to the client.

I don't start a transaction, should I ?

Thanx

[morphace]

Yes,

now I started a transaction before executing the query and it looks muuuuuuuuuuuch better :-).

What should I do with the transaction (after retrieving all the entities) ? A commit ?

What does the read-ahead option on-find mean ?

Thanx

[dsundstrom]

> Yes,
>
> now I started a transaction before executing the
> query and it looks muuuuuuuuuuuch better :-).

Thought it would.

> What should I do with the transaction (after
> retrieving all the entities) ? A commit ?

Yes.

> What does the read-ahead option on-find mean ?

The on-find strategy works on the theory that a query result is accessed in the order of the iterator. When an entity is loaded JBossCMP will load the data for that entity and the next n entities. This additional data is stored in a cache for the length of the transaction. You were accessing the entity in the least efficient way possible; you were reading ahead data and then not using it.

[morphace]

I changed everything, as you suggested, and now 982 entities are retrieved in 9427 milliseconds.

Is this looking "normal" ?

[dsundstrom]

I don't know. It compeltely depends on you setup. If it looks slow to you, hook a profiler up to it and see where the wasted time is spend.

[earlgrey]

yes, that looks like sort of "normal" behaviour. I can confirm entity instantiation within 5 - 10 msec per instance for large object graphs (> 1000 entities).
(2.4.x, no data preloading)

Lars

[cwbrandon]

Hi Dain,
This may be a dumb question, but how should you start a transaction before calling a finder for the EJBs, doesn't the container automatically start a transaction if you have the transaction attribute set to "Required" and the transaction-type attribute set to "Container"? I'm asking this because I'm having a similar problem. When I call the finder method and all the EJBs are retrieved its very fast, but when I actually access any of the attributes on any of the returned EJBs its suuuper slow (takes around a second to access several attributes on each EJB instance). Looking at the log, it appears there are excessive queries. I'm using the the Jboss-3.0.0beta2 build from today (4/5/2002). Any insight would be appreciated... thanks!

[dsundstrom]

> how should you start a transaction before calling
> a finder for the EJBs

It depends where the code is.

If you are in another EJB, you just need to set tx required on the method.

If you are in a servlet or on the client side, you need to wrap the code in a user transaction. For info lookup user transaction in any EJB book or the spec. The mastering ejb 2 book is available for free download at theserverside.com.