Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4277DC9F.9000802@spree.de>
Date: Tue, 03 May 2005 22:18:39 +0200
From: Michael Bouschen <mbo.tech@spree.de>
Organization: Tech@Spree Engineering
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
Subject: Re: pmf not closed
References: <42727265.7070100@sun.com> <42753BBE.6060000@spree.de>
 <42768B2B.70600@sun.com> <4276A522.5030104@spree.de>
 <4276BA65.5000700@sun.com>
In-Reply-To: <4276BA65.5000700@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Michelle,

thanks for testing.

> Hi, Michael,
>
> The tests still don't pass because you are attempting to delete the 
> PCPoints before the PCRects.  Even though it is one transaction, you 
> have to change the order as I did below.

I agree we need to change the order and delete PCRect instances first as 
you suggest. The cleanup code should succeed in any case. But maybe this 
scenario is an interesting test for the TCK delete test. I think the JDO 
implementation should reorder the SQL DELETE statements according to the 
foreign keys in the database such that the transaction succeeds no 
matter which instances the user deleted first in the JDO transaction.

>
> The cleanup appears to happen correctly now so the PMF is closed.  But 
> I don't see a failure message, just "FAIL".  I don't know why this is.

Yes, just getting "FAIL" is strange. I need to run the test cases you 
suggest below and figure out the details.

Does this hold you up or does the current changes of JDO_Test and 
PersistenceManagerTest allow you to continue with the TCK tests?

Regards Michael

>
> I am using CurrentTransaction as the test case. I believe that 
> ConcurrentPersistenceManagersSameClasses leaves behind the PCRects 
> that PersistenceManagerTest then tries to delete when 
> CurrentTransaction is run.  These two run in sequence when you run 
> maven runtck.jdori, so you can just watch for them to scroll by.  Or 
> you can be more clever and just run the two tests in sequence.
>
> -- Michelle
>
> Michael Bouschen wrote:
>
>> Hi Michelle,
>>
>> good catch! Now its clear why my change could not help: it was never 
>> executed :-).
>>
>> I looked at class PersistenceManagerTest and I would like to propose 
>> two changes:
>> - Method cleanupMylib should delete the PCPoint and PCRect instances 
>> in a single transaction.
>> - Method tearDown needs to be changed such that closePMF is called in 
>> any case.
>>
>> You find a new version of PersistenceManagerTest attached. Could you 
>> do me a favor and check whether this solves the problem (together 
>> with the other change of JDO_Test). If yes I would check in 
>> PersistenceManagerTest  and JDO_Test as fix for  JIRA issue JDO-32.
>>
>> Thanks!
>>
>> Regards Michael
>>
>>> Okay, here's what was going on.  PersistenceManagerTest extends 
>>> JDO_Test and overrides its tearDown() method.  The former's 
>>> tearDown() calls cleanupMylib() before calling closePMF(). 
>>> cleanupMylib() fails on trying to clean up the database, throws an 
>>> exception, and never returns to tearDown, so closePMF() does not get 
>>> executed.
>>>
>>> cleanupMylib() fails because it attempts to delete PCPoint objects 
>>> before deleting PCRect objects that hold foreign keys to the 
>>> PCPoints.  I changed the order of execution and the tests now pass.  
>>> I will accept advice on how to avoid this problem in the future if 
>>> cleanupMylib() fails.  Here is the offending code:
>>>
>>>    /** */
>>>    protected void tearDown() {
>>>        try {
>>>            cleanup();
>>>            cleanupMylib();
>>>            closePMF();
>>>        }
>>>        catch (Throwable ex) {
>>>            if (debug) ex.printStackTrace();
>>>            if (testSucceeded) {
>>>                // runTest succeeded, but closePMF throws exception =>
>>>                // failure
>>>                fail("Exception during tearDown: " + ex);
>>>            }
>>>            else {
>>>                // runTest failed and closePMF throws exception =>
>>>                // just print the closePMF exception, otherwise the
>>>                // closePMF exception would swallow the test case 
>>> failure
>>>                if (debug)
>>>                    logger.debug("Exception during tearDown: " + ex);
>>>            }
>>>        }
>>>    }
>>>      /** */
>>>    protected void cleanupMylib() {
>>>        PersistenceManager pm = getPM();
>>>        Transaction tx = null;
>>>        try {
>>>            pm = pmf.getPersistenceManager();
>>>            tx = pm.currentTransaction();
>>>            tx.begin();
>>>            Collection c = getAllObjects(pm, PCRect.class);
>>>            pm.deletePersistentAll(c);
>>>            tx.commit();
>>>                  tx.begin();
>>>            c = getAllObjects(pm, PCPoint.class);
>>>            pm.deletePersistentAll(c);
>>>            tx.commit();
>>>        }
>>>        finally {
>>>            if ((tx != null) && tx.isActive())
>>>                tx.rollback();
>>>            if ((pm != null) && pm.isClosed())
>>>                pm.close();
>>>        }
>>>    }
>>>
>>> -- Michelle
>>>


-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin