first, thanks for pointing to this bug, it should be fixed now. Get latest from CVS (trunk or OJB_BRANCH_1_0).
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=5592
The test case I use is called ...broker.metadata.MetadataMultithreadedTest see OJB test suite classes. Test pass without problems (you can play with loops/thread number of the test).
What I don't understand is how you could find the leak, because the intention of 'per-thread-changes' use is *not* to copy the repository for each call/thread, rather to manage a bunch of different repositories
(e.g. by using MetadataManager#addProfile/loadProfile... methods).
Why you need a 'fresh'copy for each thread/call? Could be a performance problem - maybe I misinterpret your needs.
regards, Armin
Janssen, Roger wrote:
hi,
executing the code below should reproduce the memory leak [of course swap the class name for a class name present in youe repository mapping :)], so best is to execute it in a loop:
MetadataManager mm = MetadataManager.getInstance(); // tell the manager to use per thread mode mm.setEnablePerThreadChanges(true);
// e.g we get a coppy of the global repository
DescriptorRepository dr = mm.copyOfGlobalRepository();
// now we can manipulate the metadata of the copy
// .... do nothing
// set the changed repository for this thread
mm.setDescriptor(dr);
org.apache.ojb.broker.query.Query q = (org.apache.ojb.broker.query.Query) new
QueryByCriteria(Class.forName("ibanx.doc.DocumentIF"), null, true);
PersistenceBroker brokerImpl =
PersistenceBrokerFactory.defaultPersistenceBroker();
Collection c = brokerImpl.getCollectionByQuery(q);
// cleanup brokerImpl.close(); brokerImpl = null;
if(c!=null)
{
c.clear();
c = null;
} dr = null;
mm = null;
in the example above, i actually do not even change the mapping, but every time within the loop, a copy is made of the global repository, and set using ThreadLocal in MetadataManager, this action does not release the memory of the previous, but does add another copy of the repository.
even if this code is executed not directly within a loop, but within a loop, a thread is started that executes this code snippet, after which the thread ends, then also the memory is not released.
Why it is not released (does threadlocal not detect the stopping/destruction of the thread, or is threadlocal not able to identify the copy of the repository (i tried adding a hashcode method but that did not work) that has to be released) i do not know! I do know that the usage of ThreadLocal is tricky, and that this is not the first time memory leaks occur because of usage of this class.
Hope this helps a bit.
Roger Janssen
*************************************************************************
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.
If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies.
--------------------------------------------------------------------- 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]
