> > 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.
Sure. Maybe report is the wrong term. It's more like a Risk analysis. Trades
have to be re-priced under various different market scenarios, like
what-ifs, so that the Risk for portfolios can be measured under all sorts of
conditions. This usually involves analytics libraries that contain all the
'rocket science' depending on the nature of the trade for doing the pricing.
This is always done in a 3GL. So you couldn't just use SQL there.
In addition, even if the cache is preloaded and 30 minutes is acceptable
because it never falls over and restarts, you still have the issue of
archived material. Typically in a trading system, any trade that has
completed is moved to an archive database, a complete replica of the
original. Sometimes archived trades may have to be used for whatever reason
and of course they wouldn't be preloaded in the cache. That can really mess
things up in a live situation. You'd probably need a dedicated server for
them I guess.
That aside, I think that fast bulk loading of EJBs is a pretty critical area
amd that's my dilemma right now (I'm not writing a trading system btw, just
using it as an example). Do I use BMP and have to implement my own secondary
cache, or purchase TopLink and let it be the secondary cache, or do I use
CMP and put up with the limitations at the moment and hope it doesn't impede
me.
> > 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)
Ok, I know what you mean. Yes, that's what I would do if I had to implement
it myself. I wouldn't have any embedded SQL etc in my EJBs, it would all be
taken care of by a PersistenceManager class that all the EJBs would delegate
their persistence to.
Paul
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
