Hi Guys. Having just finished solving some headaches on this topic, my comment is, what are you guys doing differently from me?
One of our ex-guys was nice enough to write a mess of code to update data that an entity EJB used/stored, but rather than updating the EJB, the database was updated directly. Since the EJB (BMP) was being cached, not loaded, and had a verrry long time out (intentional), this was producing some really nasty bugs. To get the data to load, we had to stop and restart the server. And I can very that findByPrimaryKey was most definately getting called. One thing I did notice, from very early in the project. Left to its defaults, the timeout on an Entity EJB in Orion is very short. It may be unloaded between consecutive calls. For example, the following block of code did result in three calls of ejbLoad on the entity EJB until we reset the time-out. UserHome userHome = getUserHome(); //Returns home interface to UserEntityEJB User user = userHome.findByPrimayKey(username); //Returns Remote Interface to Entity EJB user.login(password); UserData data = user.getData(); I forget where off hand to set the EJB Time-out, but I think it was either the ejb-jar.xml, or the orion-ejb-jar.xml file. If you need, I can look it up and let you know. -Steve Geoff Soutter wrote: > Hi Sergey, > > Thanks for the reply. I didn't explain it very clearly did I? What I > meant was: > > "However, it appears that it goes to the database (i.e. calls _ejbLoad_ > in the Entity Bean's implementation) for every call to findByPrimaryKey, > regardless of whether it has previously read the instance with the > specified key before." > > Have you been able to get pooling of BMP entity beans working? > > Geoff > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]] On Behalf Of >> Sergey G. Aslanov >> Sent: Thursday, 10 January, 2002 6:29 PM >> To: Orion-Interest >> Subject: Re: Simple question re caching/pooling of BMP Entity Beans >> >> >> Hi Geoff >> >> Loading of beans have these stages: >> 1. calling ejbFindBy... to get the primKeys of the entities; >> 2. checking if entities with such keys are already pooled; >> 3. for every key checking: if not pooled - call ejbLoad, else >> - get instance from pool; >> >> As you see, ejbFindBy... are called always independently of >> entity is pooled or not. >> >> Thursday, January 10, 2002, 2:01:37 AM, you wrote: >> >> GS> Hi there, >> >> GS> I'm teaching myself how to use Orion and I've got a >> simple question >> GS> about caching/pooling of BMP Entity Bean instances. >> >> GS> I've created a simple app which lets me read a BMP Entity Bean >> GS> through a Session Bean. I would expect that when I call >> GS> findByPrimaryKey on my Entity Bean's home interface, Orion caches >> GS> the instance it creates so that next time I call findByPrimaryKey >> GS> for the same key, it just returns the instance it already >> has rather >> GS> than creating a new one. However, it appears that it goes to the >> GS> database (i.e. calls ejbFindByPrimaryKey in the Entity Bean's >> GS> implementation) for every call to findByPrimaryKey, regardless of >> GS> whether it has previously read the instance with the >> specified key >> GS> before. >> >> GS> I checked the list archive and it appears that someone >> has reported >> GS> a similar problem a while back but there were no replies >> GS> >> (http://www.mail-archive.com/orion-interest@orionserver.com/ms > > g17359 > GS> .htm > GS> l). > > GS> I also checked the documentation and for orion-ejb-jar.xml it states > > GS> that exclusive-write-access is true by default, and since I am not > GS> setting it I presume it's defaulting to true which should allow > GS> Orion to cache the entity beans. > > GS> So, can anyone shed any light on how whether/how I can get Orion to > GS> cache BMP entity beans? > > GS> Cheers > > GS> Geoff > > > -- > Sergey G. Aslanov, > CBOSS Group, > Web-technologies department > mailto:[EMAIL PROTECTED] > tel: +7 095 7555655 -- Stephen Davidson Java Consultant Delphi Consultants, LLC http://www.delphis.com Phone: 214-696-6224 x208
