Fine!!!
You've been very useful.

Thanks.


-----Mensaje original-----
De: Armin Waibel [mailto:[EMAIL PROTECTED] 
Enviado el: viernes, 17 de diciembre de 2004 13:54
Para: OJB Users List
Asunto: Re: RV: Cache and PersistenceBroker optimization

Alessandro Colantoni wrote:
> 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)?

yep! It depends on the used ObjectCache implementation. The default 
implementation use a static map to share all objects other 
implementations e.g. clear the local used map on PB.close call,...

For more detailed info I recommend to have a look at the source code, 
some doc you can find here
http://db.apache.org/ojb/docu/guides/objectcache.html

regards,
Armin

> 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]
> 
> 
> 

---------------------------------------------------------------------
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]

Reply via email to