All right!! Now I understood, I proposed my idea just to be sure to discard it. Yesterday I was afraid that every time I borrowed a broker it opened a connection. I have another question just for curiosity. As each broker has his own instance of a cache, how does a broker see modifications on an object done by another broker? You were referring to this point when saying (with e.g. static shared map)? Thanks for patience!!
-----Mensaje original----- De: Armin Waibel [mailto:[EMAIL PROTECTED] Enviado el: viernes, 17 de diciembre de 2004 12:15 Para: OJB Users List Asunto: Re: RV: Cache and PersistenceBroker optimization Alessandro Colantoni wrote: > Hi Armin > Thanks a lot, I'll modify all my DAOs ( what a job!!! ;-) ) and I'll try > again. If you want to optimize performance setup a performance test (with most used use-case) then you can play with different sources, settings,.... > Yesterday I took another idea to improve: > > Use a Singleton class that hold the cache, so in my DAOs I have just to > retrieve it without using a broker. > I explain with an example > > I will have the private constructor of my singleton that is called > ServiceLocator: > Private ObjectCache cache; > private ServiceLocator() { > try{ .......... > broker=...... > cache = broker.serviceObjectCache(); > }catch... > finally{broker.close()} > } > public ObjectCache getCache(){return cache} > > then in my DAO I still do: > cache= ServiceLocator().getInstance().getCache(); > Identity oid = new Identity(parametroVO,broker); > parametroVO = (ParametroVO)cache.lookup(oid); > > (ParametroVO extends ValueObject, that's why I cast to it directly) > > could this work? Again, this is exactly same that OJB internally does. OJB first lookup the cache to get the object when using PB.getObjectByIdentity(...). > What about my cache in ServiceLocator when I close the broker? > Each PB use it's own OjectCache instance (with e.g. static shared map), so it's not recommended to hold an ObjectCache instance. > If it will be still alive it will see changes (I refer DAOs putting > object in cache). > > If it works it could have good performance? > Think this will not change performance of your app. regards, Armin > Thanks for your help as always. > Ciao > > -----Mensaje original----- > De: Armin Waibel [mailto:[EMAIL PROTECTED] > Enviado el: viernes, 17 de diciembre de 2004 1:07 > Para: OJB Users List > Asunto: Re: RV: Cache and PersistenceBroker optimization > > Hi Alessandro, > > Alessandro Colantoni wrote: > >>So opening a broker, look up for cache and closing the broker > > shouldn't > >>affect my performances. >> > > > yep, as Jean-Baptiste said PB only obtain a connection from pool when > it's needed. > > >>But I'm consuming a lot the Cpu oh the application server, and The DB >>server is sleeping >> > > > hmm, you can clean up your method doing > > public ValueObject findByPrimaryKey(Integer parCodigo) > { > // handle try/catch/finally/broker.close > ... > broker = ... > // assume you use a single PK and ParametroVO is the object > // real class, so I use best performing method to build an > // Identity object > Identity oid = > broker.serviceIdentity().buildIdentity(ParametroVO.class, parCodio); > // cast to ValueObject instead? > return (ParametroVO) broker.getObjectByIdentity(oid); > ... > } > > this does internal the same as you do and should show better > performance. > > > >>An other point is that I don't use beginTransaction and commit >>transaction because I have just to retrieve data. >>Then what about the PersistenceBroker pool? > > > OJB uses to pools by default. One PB-pool and a connection-pool (default > > ConnectionFactory class, except DataSource will never be pooled). The PB > > instance was returned to pool on PB.close(). > The PB instance obtain a connection from the ConnectionFactory when do > the query. You don't use PB-tx (that's ok when read data) the connection > > was released on PB.close() call. > > regards, > Armin > > > >>Can I configure it in some way. >>Should it affect my performance if I do a very big use? >>thanks >> >>-----Mensaje original----- >>De: CLARAMONTE Jean-Baptiste [mailto:[EMAIL PROTECTED] >>Enviado el: jueves, 16 de diciembre de 2004 14:52 >>Para: 'Alessandro Colantoni ' >>Asunto: RE: Cache and PersistenceBroker optimization >> >>If I remember well a DB Connection is borrowed when you make a call to >>beginTransaction and gets back when you call commitTransaction or >>abortTransaction. >> >>PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker() > > is > >>borrowing an PersistenceBroker from the PersistenceBroker pool and >>broker.close puts it back >> >> >> >>-----Message d'origine----- >>De: Alessandro Colantoni >>A: 'OJB Users List' >>Date: 16/12/2004 14:27 >>Objet: Cache and PersistenceBroker optimization >> >> >> >>-----Mensaje original----- >>De: Alessandro Colantoni [mailto:[EMAIL PROTECTED] >>Enviado el: jueves, 16 de diciembre de 2004 14:23 >>Para: 'OJB Users List' >>Asunto: Cache and per >> >> >> >>Hi all!! >>I'm doing a very large use of caching. >>I have to do thousands of small queries that look for a small number > > of > >>entries. >> >>I'm using the connection pool of OC4J. >>The application consumes rapidly a large number of connections. >> >>I implemented the queries in DAOs that have methods like this one >> >> >>public ValueObject findByPrimaryKey(Integer parCodigo)throws >>DataAccessException{ >> PersistenceBroker broker = null; >> ParametroVO parametroVO = null; >> try{ >> broker = >>PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker(); >> parametroVO = new ParametroVO(); >> parametroVO.setParCodigo(parCodigo); >> >> Identity oid = new Identity(parametroVO,broker); >> ObjectCache cache = broker.serviceObjectCache(); >> parametroVO = (ParametroVO)cache.lookup(oid); >> if (parametroVO==null){ >> Criteria criteria = new Criteria(); >> criteria.addEqualTo("parCodigo",parCodigo); >> Query query = new QueryByCriteria(ParametroVO.class, >>criteria); >> parametroVO = >>(ParametroVO)broker.getObjectByQuery(query); >> }else { >> log.info("************parametroVO in >>cache***************"); >> } >> } catch (ServiceLocatorException e) { >> log.error("ServiceLocatorException thrown in >>ParametroDAO.findByPrimaryKey(Integer parCodigo): " + e.toString()); >> throw new DataAccessException("Error in >>ParametroDAO.findByPrimaryKey(Integer parCodigo): " + e.toString(),e); >> } catch (ClassNotPersistenceCapableException e) { >> log.error("ClassNotPersistenceCapableException thrown in >>ParametroDAO.findByPrimaryKey(Integer parCodigo): " + e.toString()); >> throw new DataAccessException("Error in >>ParametroDAO.findByPrimaryKey(Integer parCodigo): " + e.toString(),e); >> } finally { >> if (broker != null) broker.close(); >> } >> return parametroVO; >> } >> >>My question is: >>The DB connection is opened when I do >>broker = >>PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker(); >> >>and is released when I do broker.close()?; >> >>As I told, almost always the ValueObject is found in cache. >>Is there any way to check if it is in cache without opening a broker? >> >>I saw in documentation the constructor >>public Identity(java.lang.Class realClass, >> java.lang.Class topLevel, >> java.lang.Object[] pkValues) >> >>But I don't understand how to use it. >>What's the difference between realClass and topLevel? >>Does this constructor could be useful for me? >> >>Hoping someone can help me >>Thanks in advance >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >>*** We scanned this email for malicious content *** >>*** IMPORTANT: Do not open attachments from unrecognized senders *** >>*** MailSystem ASTON *** >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
