geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: TranQL/OpenEJB enforce-foreign-key-constraints
Date Mon, 13 Jun 2005 03:44:11 GMT
Aaron Mulder wrote:
> On Sun, 12 Jun 2005, Jeremy Boynes wrote:
>>They are based on the info in the logical data model which for now is 
>>defined by the relationships in the EJB model and not by the database. 
>>The architecture allows for the separation of the three models 
>>(front-end (EJB), logical and back-end (DBMS)) so at some point in the 
>>future expect this to also include information from all of those models 
>>not just the front-end one.
> 	Thanks.  Which leads me to another question:
> 	When you execute a finder, does Geronimo load all beans related to
> the target(s) or no related beans (until appropriate CMR getters are
> invoked)?  It seems like there are going to be performance issues either
> way, just different ones.  I'm hoping for "no related beans", because
> otherwise you have the potential for big graph loads which I think is the
> more painful problem of the two.
> 	I also understand that Gianny is working on some kind of CMP/CMR 
> load groups, which will solve this -- I guess it can go on the road map 
> for now.  :)

Yes, for now when you execute a finder the default is just to pull back 
the PK fields of the rows that match. You can, IIRC, override the EJB-QL 
manually and add in additional fields for a manual prefetch of 
additional CMP fields or related data.

I believe Gianny is working on extending this to allow a query to be 
specified on CMR navigation, allowing additional data to be fetched for 
any related entities (to an arbitrary depth).

The general principle in play is that there are trigger events where we 
miss the cache and go to the underlying database. When that happens, the 
query can pull back anything and the entire result is added into the 
cache. We generate default queries but for performance we would expect 
users to define pre-fetch queries that match the access pattern their 
code is using.


View raw message