Memory problem: PBStateListener[] keeps growing
Hello list readers, I'm running into a memory problem with OJB on a long running server. After a couple of weeks the heap has grown in size from +- 150 MB to over 500 MB. Today I used the jmap tool that comes with je JDK to actually dump a heap histogram: 189072640 107 org.apache.ojb.broker.PBStateListener[] 109750848 4572952 java.lang.ref.WeakReference 730359684564748 org.apache.ojb.broker.accesslayer.RsIterator$ResourceWrapper 2726718422219 byte[] 25734504302777 char[] 7466688 32 java.lang.String 7442584 57688 * ConstMethodKlass 4159032 57688 * MethodKlass 189 MB is taken up by just 107 PBStateListener arrays! If we add up the majority of WeakReference and RsIterator$ResourceWrapper instances we end up with a leak of more than 300 MB, just about the size of the unexpected heap growth we have been experiencing. After analysing the OJB source code, I found that the PBStateListener management in PersistenceBrokerAbstractImpl might be suspect. The arrays that store the listeners (permanent and temporary) only seem to be able to grow. The removeListener method is never actually called, and considering the inefficiency of the algorithms used to add and remove listeners I suspect that these methods where never meant to manage large amounts of active listeners. The removeAllListeners method only seem te be called when closing and destroying the PersistenceBrokerImpl instance. The addListener method is called on every query though, so the size of the arrays after a couple of weeks does not surprise me. WeakReferences are used to make sure no references to the actual PBStateListener implementors are leaked, but the week references themselves (and the wrappers around them) are never removed, thus causing the PBStateListener arrays to keep growing. If this analysis is correct, I don't understand why nobody else is having this problem. I must be doing something radically different (more stupid?) than most other OJB users. Is there some other way these arrays are supposed to get freed that I'm not using because of a bug in my code? If so could you point me in the right direction where I might begin looking for problems? As you can imagine this is a serious performance problem for us, so I would very much appreciate any help or advice. Regards, Pieter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Update of 1toN relationship
Hi, I experience a problem while updating a 1toN relationship: I got a contact object with has n service objects. If I create a new service with a certain contactId (foreign key for contact) and store that object, the addressed contact object does not have the newly added service in the corresponding collection immediately. Makes sense cause of the object cache. But if turn the object cache off it still takes time until I retrieve the completed collection? Auto-update is set true. Do I have to update through the contact? GreetZ Nils *mtgglf* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update of 1toN relationship
Nils Liebelt schrieb: Hello, I experience a problem while updating a 1toN relationship: I got a contact object with has n service objects. If I create a new service with a certain contactId (foreign key for contact) and store that object, the addressed contact object does not have the newly added service in the corresponding collection immediately. Makes sense cause of the object cache. But if turn the object cache off it still takes time until I retrieve the completed collection? Auto-update is set true. Do I have to update through the contact? put a contact.addService(this); in your setContact() method (imho), correct me if i'm wrong. This works for me. HTH Christoph pgp43wBizJ3Nc.pgp Description: PGP signature
RE: Update of 1toN relationship
Hi, To add a service to a contact, you have two possibilities: - you add a new service directly. But in this case you have to reload the references of the contact. You can use the method broker.retrieveAllReferences(contact) - You add a new service in the collection of services defined in contact. Then you store the contact. In this case the collection descriptior in contact must have auto-update = true. Here you are David WIESZTAL. -Original Message- From: Nils Liebelt [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 11:06 AM To: 'OJB Users List' Cc: [EMAIL PROTECTED] Subject: Update of 1toN relationship Hi, I experience a problem while updating a 1toN relationship: I got a contact object with has n service objects. If I create a new service with a certain contactId (foreign key for contact) and store that object, the addressed contact object does not have the newly added service in the corresponding collection immediately. Makes sense cause of the object cache. But if turn the object cache off it still takes time until I retrieve the completed collection? Auto-update is set true. Do I have to update through the contact? GreetZ Nils *mtgglf* - 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]
RE: Update of 1toN relationship
Sweet, Thx I am updating through the contact object now. Works fine! I am not sure if reloading actually would werk cause when retrieving the contact object again (after inserting a service) I do complete lookup by identity with auto-retrieve set true. It looks more like object cache issue. GreetZ Nils -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 12:28 PM To: ojb-user@db.apache.org Subject: RE: Update of 1toN relationship Hi, To add a service to a contact, you have two possibilities: - you add a new service directly. But in this case you have to reload the references of the contact. You can use the method broker.retrieveAllReferences(contact) - You add a new service in the collection of services defined in contact. Then you store the contact. In this case the collection descriptior in contact must have auto-update = true. Here you are David WIESZTAL. -Original Message- From: Nils Liebelt [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 11:06 AM To: 'OJB Users List' Cc: [EMAIL PROTECTED] Subject: Update of 1toN relationship Hi, I experience a problem while updating a 1toN relationship: I got a contact object with has n service objects. If I create a new service with a certain contactId (foreign key for contact) and store that object, the addressed contact object does not have the newly added service in the corresponding collection immediately. Makes sense cause of the object cache. But if turn the object cache off it still takes time until I retrieve the completed collection? Auto-update is set true. Do I have to update through the contact? GreetZ Nils *mtgglf* - 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]
[newbie] ODMG API : updating an object's primary key.
Hi,
I try to use the ODMG API of OJB.
I noticed that, if I read an object from the database, then modify a property
that is declared as a primary key (in the mapping) and save the object to the
database, a new row is created as if it was a new object inserted.
Is there a way to modify an object's primary key without having to delete it
from the database before ?
follows a sample code.
---
class-descriptor
class=year
table=numord
field-descriptor
name=year
column=annee
primarykey=true
/
/class-descriptor
public class year {
private int year;
public int getYear() {
return year;
}
public void setYear(int year) {
this.year = year;
}
}
public class test {
public static void main(String[] args) {
year y = new year();
try {
Implementation impl = OdmgSingleton.odmg;
//OdmgSingleton is a static class of mine.
Transaction t = impl.newTransaction();
t.begin();
org.odmg.OQLQuery query = impl.newOQLQuery();
query.create(select p from year);
DList results = (DList)query.execute();
y = (year)results.iterator().next();
t.lock(y,Transaction.WRITE);
y.setYear(2004);
t.commit();
} catch (Exception e) {
e.printStackTrace();
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] ODMG API : updating an object's primary key.
Why would you want to do that ? The primary key identifies the object uniquely, so if you change the value of the corresponding java field(s), then OJB and the database think that you have created a new instance of the class/new row in the table. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] ODMG API : updating an object's primary key.
Actually the concept of primary key is not always used in a database. Let's imagine a table person with fields firstname and lastname but no id. As OJB needs a primary key I will use the couple (firstname,lastname) as a primary key for the mapping. But if I change the property firstname in the java object, it is still the same object and not a new one. -Message d'origine- De : Thomas Dudziak [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 février 2005 13:28 À : OJB Users List Objet : Re: [newbie] ODMG API : updating an object's primary key. Why would you want to do that ? The primary key identifies the object uniquely, so if you change the value of the corresponding java field(s), then OJB and the database think that you have created a new instance of the class/new row in the table. Tom - 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]
Re: [newbie] ODMG API : updating an object's primary key.
But as far as OJB and the database is concerned, it is a new one, because they cannot determine to which 'old' one it corresponds. The problem here is that OJB and the database use object equality (if two objects are equal as determined by equals()/hashCode()) whereas you want to use identity (same java object as determined by ==, i.e. location in memory). So you either got to delete the old object/row and then insert the new one, or introduce a separate primary key. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] ODMG API : updating an object's primary key.
ok. Thank you. -Message d'origine- De : Thomas Dudziak [mailto:[EMAIL PROTECTED] Envoyé : mercredi 9 février 2005 13:52 À : OJB Users List Objet : Re: [newbie] ODMG API : updating an object's primary key. But as far as OJB and the database is concerned, it is a new one, because they cannot determine to which 'old' one it corresponds. The problem here is that OJB and the database use object equality (if two objects are equal as determined by equals()/hashCode()) whereas you want to use identity (same java object as determined by ==, i.e. location in memory). So you either got to delete the old object/row and then insert the new one, or introduce a separate primary key. Tom - 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]
Re: Memory problem: PBStateListener[] keeps growing
Armin wrote: I think your analysis is correct and the listener show the expected behavior, see javadoc http://db.apache.org/ojb/api/org/apache/ojb/broker/PersistenceBroker.html#addListener(org.apache.ojb.broker.PBListener) the temporary listener will only be removed on the PB.close() call. It's strongly recommended to close each used PB instance immediately after use (or guarantee that it is happen sometime), because only in this case OJB is able to do all needed cleanup. All PB instances are pooled, so this procedure doesn't affect performance. Here is a usage example http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#A+First+Look+-+Persisting+New+Objects Did you use the PB-api in the same way? Apparantly not ;-) Seriously, I've studied the example you quote before I started coding, but I interpreted it wrongly. I though I would be save if I requested a PersistenceBroker only once and then reused it throughout my application (as long as I used one instance per thread as I learned the hard way ;-). Why is it inefficient? Because we use System.arraycopy calls? How many active listener do you use between PB lookup and close? There is no problem if I use the PB api the way you describe. I will fix my application to close the broker after use and reopen an new one when needed. This will probably even simplify my code because I do not need ThreadLocal variables to keep track of a single PersistenceBroker object per thread anymore. Thanks for the tip and thanks for a great product! OJB has saved me hundreds of hours of development time and helped me eradicate almost all traces of SQL from my application ;-) Regards, Pieter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pool Info?
I'm using ConnectionFactoryPooledImpl and I'm trying to find run time information about the pool such as the current number of connections checked out, and the number of connections that were timed out etc. Is there any way to get this data?
Re: Pool Info?
Hi Bob,
currently there are no methods to access the used commons-pool instances
in ConnectionFactoryPooledImpl. I recommend to extend
ConnectionFactoryPooledImpl and override method #createConnectionPool.
public ObjectPool createConnectionPool(JdbcConnectionDescriptor jcd)
{
ObjectPool pool = super.createConnectionPool...
// add 'pool' instance to list or map, ObjectPool has methods to
// lookup active connections, idle connections ...
return pool;
}
regards,
Armin
Bob Damato wrote:
I'm using ConnectionFactoryPooledImpl and I'm trying to find run time information about
the pool such as the current number of connections checked out, and the
number of connections that were timed out etc. Is there any way to get this data?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ObjectCacheOSCacheImpl issue.
I'm trying to use OSCache with OJB as I need disk persistence. My setup is working great with the other cache implementations. I got ObjectCacheOSCacheImpl.java from the db-obj-1.0.1-contrib package, set up oscache-2.1, and set ObjectCacheClass to ObjectCacheOSCacheImpl in my config. When I run it I get the following error, where OJB appears to be trying to pass a Properties object to ObjectCacheOSCacheImpl's constuctor: java.lang.NoSuchMethodException: ObjectCacheOSCacheImpl.init(org.apache.ojb.broker.PersistenceBroker, java.util.Properties) I see that the constructors that ObjectCacheOSCacheImpl does have are all empty, so just for fun I added an empty constructor with the profile that OJB was looking for. The Properties object that is passed is null, by the way. Once I added this constructor, OJB ran and was fetching data from the database. I could also see log output from OSCache itself like Creating cache. Also it created a disk cache directory on the system, but doesn't write any files there. OJB does not seem to be calling cache() or lookup() on ObjectCacheOSCacheImpl ( I put some logging in it to see if it was). Here are my ojb properties in case there is anything relevant there: repositoryFile=ojb_repository.xml useSerializedRepository=false serializedRepositoryPath=. PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl maxActive=100 maxIdle=-1 maxWait=2000 timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=100 whenExhaustedAction=0 ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl ObjectCacheClass=ObjectCacheOSCacheImpl descriptorBasedCaches=false LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl LockTimeout=6 ImplicitLocking=true LockServletUrl=http://127.0.0.1:8080/ojb-lockserver LockAssociations=WRITE OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2 SqlInLimit=200 ImplementationClass=org.apache.ojb.odmg.ImplementationImpl OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager DListClass=org.apache.ojb.odmg.collections.DListImpl_2 DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2 DMapClass=org.apache.ojb.odmg.collections.DMapImpl DBagClass=org.apache.ojb.odmg.collections.DBagImpl DSetClass=org.apache.ojb.odmg.collections.DSetImpl PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ObjectCacheOSCacheImpl issue.
Hi Michael, Michael Newton wrote: I'm trying to use OSCache with OJB as I need disk persistence. My setup is working great with the other cache implementations. I got ObjectCacheOSCacheImpl.java from the db-obj-1.0.1-contrib package, set up oscache-2.1, and set ObjectCacheClass to ObjectCacheOSCacheImpl in my config. When I run it I get the following error, where OJB appears to be trying to pass a Properties object to ObjectCacheOSCacheImpl's constuctor: java.lang.NoSuchMethodException: ObjectCacheOSCacheImpl.init(org.apache.ojb.broker.PersistenceBroker, java.util.Properties) I see that the constructors that ObjectCacheOSCacheImpl does have are all empty, so just for fun I added an empty constructor with the profile that OJB was looking for. The Properties object that is passed is null, by the way. Once I added this constructor, OJB ran and was fetching data from the database. all ObjectCache implementations need a specific constructor expect an PB and Properties type. Thus you be right. I could also see log output from OSCache itself like Creating cache. Also it created a disk cache directory on the system, but doesn't write any files there. OJB does not seem to be calling cache() or lookup() on ObjectCacheOSCacheImpl ( I put some logging in it to see if it was). hmm, if OJB never calls cache or lookup in ObjectCacheOSCacheImpl it will never call these methods on all ObjectCache implementations, because they are all handled in the same way. Did you write a test case to check the cache? Something like Article a = new Article(); Identity oid = broker.serviceIdentity().buildIdentity(a); broker.serviceObjectCache().cache(oid, a); Article b = broker.serviceObjectCache().lookup(oid); assertNotNull(b); This test should pass with ObjectCacheDefaultImpl and your ObjectCacheOSCacheImpl too. regards, Armin Here are my ojb properties in case there is anything relevant there: repositoryFile=ojb_repository.xml useSerializedRepository=false serializedRepositoryPath=. PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl maxActive=100 maxIdle=-1 maxWait=2000 timeBetweenEvictionRunsMillis=-1 minEvictableIdleTimeMillis=100 whenExhaustedAction=0 ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl ObjectCacheClass=ObjectCacheOSCacheImpl descriptorBasedCaches=false LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl LockTimeout=6 ImplicitLocking=true LockServletUrl=http://127.0.0.1:8080/ojb-lockserver LockAssociations=WRITE OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2 SqlInLimit=200 ImplementationClass=org.apache.ojb.odmg.ImplementationImpl OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager DListClass=org.apache.ojb.odmg.collections.DListImpl_2 DArrayClass=org.apache.ojb.odmg.collections.DListImpl_2 DMapClass=org.apache.ojb.odmg.collections.DMapImpl DBagClass=org.apache.ojb.odmg.collections.DBagImpl DSetClass=org.apache.ojb.odmg.collections.DSetImpl PersistentFieldClass=org.apache.ojb.broker.metadata.fieldaccess.PersistentFieldDirectAccessImplNew JTATransactionManagerClass=org.apache.ojb.broker.transaction.tm.JBossTransactionManagerFactory - 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]
Re: ObjectCacheOSCacheImpl issue.
I wrote a test as you suggested and it actually passed for both
ObjectCacheOSCacheImpl and for the ObjectCacheDefaultImpl
I have print statements in the constructor, lookup, and cache methods
in ObjectCacheOSCacheImpl.
Here is my test:
public void testCache () throws Exception {
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
Attribute a = new Attribute();
Identity oid = broker.serviceIdentity().buildIdentity(a);
broker.serviceObjectCache().cache(oid, a);
Attribute b = (Attribute) broker.serviceObjectCache().lookup(oid);
assertNotNull(b);
}
and here is the output (running with ObjectCacheOSCacheImpl )
[junit] Testsuite: legion.service.CacheTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.472 sec
[junit] - Standard Output ---
[junit] OSCache constructor
[junit] -
No OSCache lookup or OSCache cache messages are printed, and
OSCache does not write it's disk cache (although it creates the
directory)
So what's going on here?
M.
On Thu, 10 Feb 2005 02:32:42 +0100, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Michael,
Michael Newton wrote:
I'm trying to use OSCache with OJB as I need disk persistence.
My setup is working great with the other cache implementations.
I got ObjectCacheOSCacheImpl.java from the db-obj-1.0.1-contrib
package, set up oscache-2.1, and set ObjectCacheClass to
ObjectCacheOSCacheImpl in my config.
When I run it I get the following error, where OJB appears to be
trying to pass a Properties object to ObjectCacheOSCacheImpl's
constuctor:
java.lang.NoSuchMethodException:
ObjectCacheOSCacheImpl.init(org.apache.ojb.broker.PersistenceBroker,
java.util.Properties)
I see that the constructors that ObjectCacheOSCacheImpl does have are
all empty, so just for fun I added an empty constructor with the
profile that OJB was looking for. The Properties object that is passed
is null, by the way.
Once I added this constructor, OJB ran and was fetching data from the
database.
all ObjectCache implementations need a specific constructor expect an PB
and Properties type. Thus you be right.
I could also see log output from OSCache itself like
Creating cache. Also it created a disk cache directory on the
system, but doesn't write any files there.
OJB does not seem to be calling cache() or lookup() on
ObjectCacheOSCacheImpl ( I put some logging in it to see if it was).
hmm, if OJB never calls cache or lookup in ObjectCacheOSCacheImpl it
will never call these methods on all ObjectCache implementations,
because they are all handled in the same way.
Did you write a test case to check the cache? Something like
Article a = new Article();
Identity oid = broker.serviceIdentity().buildIdentity(a);
broker.serviceObjectCache().cache(oid, a);
Article b = broker.serviceObjectCache().lookup(oid);
assertNotNull(b);
This test should pass with ObjectCacheDefaultImpl and your
ObjectCacheOSCacheImpl too.
regards,
Armin
Here are my ojb properties in case there is anything relevant there:
repositoryFile=ojb_repository.xml
useSerializedRepository=false
serializedRepositoryPath=.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
maxActive=100
maxIdle=-1
maxWait=2000
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=100
whenExhaustedAction=0
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
ObjectCacheClass=ObjectCacheOSCacheImpl
descriptorBasedCaches=false
LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
LockTimeout=6
ImplicitLocking=true
LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
LockAssociations=WRITE
OqlCollectionClass=org.apache.ojb.odmg.collections.DListImpl_2
SqlInLimit=200
ImplementationClass=org.apache.ojb.odmg.ImplementationImpl
OJBTxManagerClass=org.apache.ojb.odmg.LocalTxManager
Re: ObjectCacheOSCacheImpl issue.
So what's going on here?
are you sure that OSCache is really used by OJB? You set the OSCache
in OJB.properties, but is a cache in repository_database.xml file
(object-cache element in in the jdbc-connection-descriptor) set too? Are
specific caches set for classes (object-cache element in class-descriptor)?
regards,
Armin
Michael Newton wrote:
I wrote a test as you suggested and it actually passed for both
ObjectCacheOSCacheImpl and for the ObjectCacheDefaultImpl
I have print statements in the constructor, lookup, and cache methods
in ObjectCacheOSCacheImpl.
Here is my test:
public void testCache () throws Exception {
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
Attribute a = new Attribute();
Identity oid = broker.serviceIdentity().buildIdentity(a);
broker.serviceObjectCache().cache(oid, a);
Attribute b = (Attribute) broker.serviceObjectCache().lookup(oid);
assertNotNull(b);
}
and here is the output (running with ObjectCacheOSCacheImpl )
[junit] Testsuite: legion.service.CacheTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.472 sec
[junit] - Standard Output ---
[junit] OSCache constructor
[junit] -
No OSCache lookup or OSCache cache messages are printed, and
OSCache does not write it's disk cache (although it creates the
directory)
So what's going on here?
M.
On Thu, 10 Feb 2005 02:32:42 +0100, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Michael,
Michael Newton wrote:
I'm trying to use OSCache with OJB as I need disk persistence.
My setup is working great with the other cache implementations.
I got ObjectCacheOSCacheImpl.java from the db-obj-1.0.1-contrib
package, set up oscache-2.1, and set ObjectCacheClass to
ObjectCacheOSCacheImpl in my config.
When I run it I get the following error, where OJB appears to be
trying to pass a Properties object to ObjectCacheOSCacheImpl's
constuctor:
java.lang.NoSuchMethodException:
ObjectCacheOSCacheImpl.init(org.apache.ojb.broker.PersistenceBroker,
java.util.Properties)
I see that the constructors that ObjectCacheOSCacheImpl does have are
all empty, so just for fun I added an empty constructor with the
profile that OJB was looking for. The Properties object that is passed
is null, by the way.
Once I added this constructor, OJB ran and was fetching data from the
database.
all ObjectCache implementations need a specific constructor expect an PB
and Properties type. Thus you be right.
I could also see log output from OSCache itself like
Creating cache. Also it created a disk cache directory on the
system, but doesn't write any files there.
OJB does not seem to be calling cache() or lookup() on
ObjectCacheOSCacheImpl ( I put some logging in it to see if it was).
hmm, if OJB never calls cache or lookup in ObjectCacheOSCacheImpl it
will never call these methods on all ObjectCache implementations,
because they are all handled in the same way.
Did you write a test case to check the cache? Something like
Article a = new Article();
Identity oid = broker.serviceIdentity().buildIdentity(a);
broker.serviceObjectCache().cache(oid, a);
Article b = broker.serviceObjectCache().lookup(oid);
assertNotNull(b);
This test should pass with ObjectCacheDefaultImpl and your
ObjectCacheOSCacheImpl too.
regards,
Armin
Here are my ojb properties in case there is anything relevant there:
repositoryFile=ojb_repository.xml
useSerializedRepository=false
serializedRepositoryPath=.
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
PersistenceBrokerClass=org.apache.ojb.broker.core.PersistenceBrokerImpl
maxActive=100
maxIdle=-1
maxWait=2000
timeBetweenEvictionRunsMillis=-1
minEvictableIdleTimeMillis=100
whenExhaustedAction=0
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryPooledImpl
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
SqlGeneratorClass=org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl
IndirectionHandlerClass=org.apache.ojb.broker.core.proxy.IndirectionHandlerDefaultImpl
ListProxyClass=org.apache.ojb.broker.core.proxy.ListProxyDefaultImpl
SetProxyClass=org.apache.ojb.broker.core.proxy.SetProxyDefaultImpl
CollectionProxyClass=org.apache.ojb.broker.core.proxy.CollectionProxyDefaultImpl
StatementManagerClass=org.apache.ojb.broker.accesslayer.StatementManager
StatementsForClassClass=org.apache.ojb.broker.accesslayer.StatementsForClassImpl
JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
RowReaderDefaultClass=org.apache.ojb.broker.accesslayer.RowReaderDefaultImpl
ObjectCacheClass=ObjectCacheOSCacheImpl
descriptorBasedCaches=false
LockManagerClass=org.apache.ojb.odmg.locking.LockManagerDefaultImpl
LockMapClass=org.apache.ojb.odmg.locking.InMemoryLockMapImpl
LockTimeout=6
ImplicitLocking=true
LockServletUrl=http://127.0.0.1:8080/ojb-lockserver
LockAssociations=WRITE
