In the meantime I trying to add some simple caching to my BMP beans. I'm already using coarse grain entity beans so my loading of dependent objects is optimized. I'd really like to avoid the N+1 fetch problem for the entity beans themselves if I can. My goal is to reduce the average number of fetches, but I don't have to always get down to 1. I am thinking of fetching all the data on a finder and saving it in a cache (by type of entity) object with the PK as the key. When the load request comes along I'll check to see if it's in the cache and pull it out if it is. If not I'll load from the database. On an ejbStore I'll clear the entry out of the cache to avoid getting stale data from the cache. I'll setup the cache as a circular buffer (and some hashtable for fast lookup) of fixed size so as to not eat up all of memory in the process. I was hoping to put the optimistic locking version into the PK, but hidden from the container, but that seems to be impossible with the current CacheKey implementation, so I'll have to live without it. I would appreciate comments on this scheme... Cheers Jay Walters -----Original Message----- From: Jay Walters [mailto:[EMAIL PROTECTED]] Sent: Friday, November 10, 2000 9:57 AM To: 'jBoss' Subject: RE: [jBoss-User] finder Optimization in Jaws Just want to figure out if it's on the list ahead of EJB 2.0 or behind it... I know you guys are busy enough from the traffic on jboss-dev... -----Original Message----- From: Rickard Oberg [mailto:[EMAIL PROTECTED]] Sent: Friday, November 10, 2000 9:53 AM To: jBoss Subject: Re: [jBoss-User] finder Optimization in Jaws Hi! > >> How do I get CMP to load all of this data in one single SELECT ? Does it > >> depend on the vendor ? > >> > > Yes. There is really no need for the CMP-implementor to do a select for > > each bean (AFAIK). If I haven't missed anything then it should be a > > pretty obvious optimization for CMP-implementors to do. > > > > /Rickard > > > > After a review of the Jaws source code it appears jBoss/Jaws doesn't > currently perform this optimization. Correct. > Any plans to add it? Yes. Time...so much to do so little time... /Rickard -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED] -- -------------------------------------------------------------- To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Problems?: [EMAIL PROTECTED]
