Build some BMP beans that work across jBoss, JRun and Weblogic and that
support dependent objects with reasonable performance and without adding an
extra product like CocoBase to the mix. Right now I am generating the
entity beans along with a bunch of other artifacts from a UML model.
So the cache in question is an application object accessed from my EJBs, I
am not considering doing anything with the container itself since I can't do
the same with the COTS containers.
Cheers
Jay Walters
-----Original Message-----
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 10, 2000 11:58 AM
To: jBoss
Subject: RE: [jBoss-User] finder Optimization in Jaws/BMP Entity Caching
|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
you are talking about our caches?
|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.
hmmmm the cacheKey is returned by the cache. If you want to extend a cache
we can help you and also you should be able to extend "cachekey" and give
whatever behaviour you like. It was designed to be pluggable for key
implementations :)
I am not entirely sure I understand what you are trying to do though...
marc
|
|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]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
