I'm not one of the JOnAS engineers so I can't speak for what they may
have already done to address this issue. However, the issue of
container performance has been cropping up in the architecture group
quite a bit and I'm sorry if I didn't cross-post that discussion.
I've been arguing for a rewrite (unfortunately) of the way in which the
entity containers implement object caching. I believe an effective
solution to your issue is to have the container manage a client-side
(read JOnAS process space) cursor on the database that is updated by the
db as needed and is used like a paging mechanism. If the object is not
in cache (i.e. on disk) then a fault occurs in the container while it
moves the cursor window to encompass the desired reference. If you're
looking for items in a large table (1000+ rows) then maybe we will also
need to include a deployment parameter to hint at the database table
size for the object as a proprietary extension (in the descriptor only,
not code!!) to the J2EE model. Anyway, the result will be that the
entire table should be cached on a multi-row basis so that internal
queries like findByPrimaryKey("foo") should be as fast as a bean-bean
call unless there is a cache miss on the cursor. It is the
responsibility of the container to provide better object caching. This
particular characteristic of existing EJB implementations has been
widely criticized by the likes of IBM, but can be effectively remedied
with a solution like the one I just outlined. I wish I could help make
it happen, but I'm currently up to my eyeballs in system configuration
and architecture issues.
I hope this sees its way to the right folks.
Cheers!
Adam
Bryan Field-Elliot wrote:
>
> We use CMP beans extensively, and I am examing the code generated by GenIC
> for "JOnAS###Bean###Home" and "JOnAS###Bean###" (where ### is the name of my
> bean). This is the code which implements the JEntityHome and JBeanEntity
> interfaces.
>
> It seems that _two_ queries get issued for every finder method, but it seems
> to me that the job can be done with only one. This is a big performance
> problem for us, and would be a great performance boost if we could make it
> into one query.
>
> For example, if I have a table called "Employees" with a primary key "id"
> and other fields "name" and "job", then a findByPrimaryKey(100) would result
> in the following two queries:
>
> select Employees.id from Employees where Employees.id=?
> select Employees.id, Employees.name, Employees.job from Employees where
> Employees.id=?
>
> The first is issued by the Home interface implementation
> (pkFindByPrimaryKey), and the second is implemented by the Bean
> implementation (loadData).
>
> As far as I can see, the first query is a big waste of resources, and pretty
> much cuts performance in half. I don't understand why the first query is
> executed at all, since it's function (to check whether or not the row
> exists) can be performed by the second query just as well.
>
> Can someone please explain why it works this way, and if possible, how to
> optimize it?
>
> Thank you,
> Bryan
>
>
> ----
> This list is cross-posted to two mail lists. To unsubscribe,
> follow the instructions below for the list you subscribed to.
> For objectweb.org: send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe ejb-container-group".
> For enhydra.org: send email to [EMAIL PROTECTED] and include
> in the body of the message "unsubscribe ejb-container-group".
----
This list is cross-posted to two mail lists. To unsubscribe,
follow the instructions below for the list you subscribed to.
For objectweb.org: send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe ejb-container-group".
For enhydra.org: send email to [EMAIL PROTECTED] and include
in the body of the message "unsubscribe ejb-container-group".
