> From: danch (Dan Christopherson) [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 15, 2001 10:47 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Avoiding big numbers of selects loading EJB
> cache
>
>
> > If the cache is empty on startup, and you have a finder method returning
> > say 5000 objects, then that will generate 5000 individual selects to the
> > database, not very efficient. I have seen a third party trading system
> > done using BMP
> > on WebLogic whereby initially they have to load up a portfolio of
> > 100,000 trades to run a Risk report on them. Takes about 30 minutes plus
> > to start it up. Not nice.
>
>
> Reporting off of EJBs is probably not the best implementation choice at
> this point in specdom - you'll be much kinder on your servers if you
> report the old fashioned way.
I know what you're saying, but you want to deal with objects rather than
data, and encode most business logic on the EJB server so it's accessible to
all rather than have it in stored procedures (if that's what you mean by the
old fashioned way?). There are also lots of other session beans to do with P
& L, and booking a trade and all the rest all using the same data so you
would get cross benefits having it in the cache. Reports would be running
concurrently with all of this.
It's just that EJB is a bit lacking at the moment in that area like you say,
however, with CMP making headway, it should hopefully get to a stage whereby
BMP for the most part is just not necessary, that is certainly highly
desirable as far as I'm concerned. I'm all for EJBQL, I think that too much
developer time is spent on EJB systems worrying about persistence because of
the limitations to date of CMP.
>
> But yes, this will be very ugly with BMP, no matter what app server
> you're using.
That's what I feared.
> I'm not sure, but I think it's more likely that WebLogic + TopLink wind
> up with a two level cache.
It may be. I mailed their support some time ago as I did quite a bit of
prototyping
with TOpLInk (not for EJBs for the most part, ordinary objects most of the
time). THey said that WebLogic just uses their cache when it's plugged in.
I liked TopLink quite a lot I have to say, very comprehensive API.
> > Method findByXXX called.
> >
> > Delegated to ejbFindByXXX
> >
> > Select query to database.
> >
> > Iterate through results set.
> >
> > Get the primary key from each row
> >
> > Check if it's in the cache.
> >
> > If it is not, create a new EJB and populate it from the result set and
> > insert it into the cache
>
>
> This you really can't do. The container must be allowed to control the
> lifecycle of EJB instances.
Absolutely, I just wanted to show how impossible it seemed.
> See the 'fat-key' pattern on theserverside.com. WARNING: this may
> significantly degrade JBoss' cache performance!
I shall take a look.
>
> Do you use data access objects? If so, consider creating a static
> 'read-ahead buffer' in the data access object for a particular entity.
> Use weak references for the objects, and the PK for the key. in
> ejbFindByPrimaryKey, check the read ahead before executing SQL.
Do you mean JDO for data access objects?
> > Would JAWS CMP do it efficiently?
>
>
> It will.
Well that's good news.
THanks for your information.
Paul
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
