EJB: ONE query for multiple rows

[Timo Nentwig]

Hi!

Beans are used to be fetched from DB by countless single SELECT statements
which I more than stupid.

This must be something I misunderstood about EJBs, isn't it possible to
fetch multiple rows/beans with one SELECT? Getting row after row will trash
performance of any DB and hence you could not even build mid-size system
with EJBs.

 

[Sudsy]

Hi!

Beans are used to be fetched from DB by countless single SELECT statements
which I more than stupid.

This must be something I misunderstood about EJBs, isn't it possible to
fetch multiple rows/beans with one SELECT? Getting row after row will trash
performance of any DB and hence you could not even build mid-size system
with EJBs.

I'm having to read a lot into your post since you don't offer much detail.
If you're talking about entity EJBs then investigate finder methods.
They can return collections of beans.

 

[Timo Nentwig]

If you're talking about entity EJBs then investigate finder methods.

See subject ("EJB: ..."). Yes, I'm talking about EJBs.

They can return collections of beans.

Can you offer some more details?

 

[Andrew Thompson]

See subject ("EJB: ..."). Yes, I'm talking about EJBs.

It's alway wise to repeat each word (or acronym)
of the subject in the body of your post.

A lot of folks (myself included) mostly
ignore the 'subject' line.

HTH

 

[Sudsy]

Sudsy wrote:




See subject ("EJB: ..."). Yes, I'm talking about EJBs.




Can you offer some more details?

The topic is complex and implementation depends on whether you're using
BMP or CMP. I just went to the Sun site and entered "+entity +finder
+method" as the query. The third hit is this one:
<http://java.sun.com/developer/onlineTraining/Programming/JDCBook/code5.html>
There's lots of reading to do, but the Sun site should always be one of
your first sources of information. I don't want to waste bandwidth on
this ng explaining what is already well-covered.
Best wishes!

 

[Timo Nentwig]

Ok, more precisely this time. I don't develop EJBs, I'm just wondering what
the EJB developer are telling me: the finder methods only get the IDs of
the rows, the row itself is actually fetch on first access. I.e. my finder
method may return the IDs of 1000 rows and then will fetch (SELECT) each
single one of them when I access them (i.e. iterator over the collection).

I can't believe that EJB is that silly...

 

[Sudsy]

Ok, more precisely this time. I don't develop EJBs, I'm just wondering what
the EJB developer are telling me: the finder methods only get the IDs of
the rows, the row itself is actually fetch on first access. I.e. my finder
method may return the IDs of 1000 rows and then will fetch (SELECT) each
single one of them when I access them (i.e. iterator over the collection).

I can't believe that EJB is that silly...

How do you mean "silly"? Entity beans exist to represent the state of a
row in a database table or view. Yes, finder methods return an array of
primary key objects to the J2EE container.
But the client receives a collection of local or remote interfaces. The
J2EE server handles the mapping and will populate entity EJBs from the
underlying table or view as needed.
Are you worried about the overhead? Performing a fetch by primary key
does not tax the DB as would a regular SELECT with constraints. But you
might want to consult the appropriate resources or run your own numbers
if you're unconvinced.

 

[Timo Nentwig]

How do you mean "silly"? Entity beans exist to represent the state of a

I likely use all the rows I find with the finder method (hence "finder"
method as it does find what I am looking for). So, why does the container
fetch one row after another?

 

[Sudsy]

I likely use all the rows I find with the finder method (hence "finder"
method as it does find what I am looking for). So, why does the container
fetch one row after another?

What happens when you use a ResultSet? Do you think all of the matching
rows are presented to your client at once? What then of the setFetchSize
method?
It's difficult to explain all the magic which goes on "under the covers"
which is why I suggested you find a good reference and do some reading.
Suffice it to say that entity beans are cached and re-used.
No sense boring everyone with the details. Most will likely never have
need for entity beans...

 

[Timo Nentwig]

What happens when you use a ResultSet? Do you think all of the matching
rows are presented to your client at once? What then of the setFetchSize
method?

It is ONE query that the database does process; setFetchsize() is only about
not holding all the data concurrently in RAM.

After all EJB is f*ckingly slow due to an endless count of single stupid
SELECTs fired at the RDBMS.