Paul Hammond wrote:
>>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.
How sophisticated are the reports? I see a lot of reports that don't
really have any logic about them, other than grouping, summing, etc -
the things that relational databases have been tuned to do well. If
there is logic beyond what standard SQL queries can do, I think you are
correct that that should be in a bean somewhere. You might consider
writing stateless session beans issuing SQL directly, bypassing the
entity layer, if the logic isn't used elsewhere. Not the purist
approach, certainly, but I'm personnally willing to get dirty to get
things to work acceptably.
>
> 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.
True.
>
> Do you mean JDO for data access objects?
No, I just ment any abstraction that would give you a separate
persistence layer beneath your beans. This would be a good place to hook
up that read-ahead cache. (a second level cache)
-danch
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
