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]
