Re: pmf not closed
Hi Michelle, [...] Does this hold you up or does the current changes of JDO_Test and PersistenceManagerTest allow you to continue with the TCK tests? This is not holding me up. You can check in now or later, whatever works for you. I checked in the changes of JDO_Test and PersistenceManagerTest. Regads Michael -- Michael Bouschen[EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED]http://www.tech.spree.de/ Tel.:++49/30/235 520-33 Buelowstr. 66 Fax.:++49/30/2175 2012 D-10783 Berlin
Re: pmf not closed
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.
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.
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
Re: pmf not closed
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[EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED]http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: pmf not closed
Hi, Michael, Responses in-line... Michael Bouschen wrote: 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. Interesting point. I hadn't considered that. Is it in the spec? 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. In general, the tests are not giving as much feedback when they fail as I would expect. Does this hold you up or does the current changes of JDO_Test and PersistenceManagerTest allow you to continue with the TCK tests? This is not holding me up. You can check in now or later, whatever works for you. Thanks!! -- Michelle 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
Re: pmf not closed
Quoting Michael Bouschen [EMAIL PROTECTED]: 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. If the fields lowerRight and upperLeft ate set as dependent in the metadata, this will probably solve the issue. Regards, Erik Bengtson
Re: pmf not closed
Hi Michelle,
Hi, Michael,
When you get a chance to look at the tests that don't close pmf when
they fail, the JIRA number is JDO-32.
I looked into this. Attached you find an updated version of
JDO_Test.java. It checks whether pmf.close throws an exception because
of open pms. If so it closes the pms and closes the pmf again.
However, I was not able to reproduce the issue. I removed the heap size
increase from project.properties. I also added some debug messages to
the pm cleanup code I added to the method closing the pmf. It got never
printed. I tried the tck default configuration and used the JPOX nightly
builds from April 1 and May 1.
Could you please try the attached version of JDO_Test and let me know
whether it makes any difference? It might be good to check it in anyway,
even if todays tests do not need it.The attached file works for tck20
and tck11 and I'm planning a similar change for ri11.
Thanks!
Regards Michael
Thanks,
Michelle
--
Michael Bouschen[EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED]http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
/*
* Copyright 2005 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.jdo.tck;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Field;
import java.util.Properties;
import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;
import javax.jdo.JDOException;
import junit.framework.TestCase;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public abstract class JDO_Test extends TestCase {
public static final int TRANSIENT = 0;
public static final int PERSISTENT_NEW = 1;
public static final int PERSISTENT_CLEAN= 2;
public static final int PERSISTENT_DIRTY= 3;
public static final int HOLLOW = 4;
public static final int TRANSIENT_CLEAN = 5;
public static final int TRANSIENT_DIRTY = 6;
public static final int PERSISTENT_NEW_DELETED = 7;
public static final int PERSISTENT_DELETED = 8;
public static final int PERSISTENT_NONTRANSACTIONAL = 9;
public static final int NUM_STATES = 10;
public static final int ILLEGAL_STATE = 10;
public static final String[] states = {
transient,
persistent-new,
persistent-clean,
persistent-dirty,
hollow,
transient-clean,
transient-dirty,
persistent-new-deleted,
persistent-deleted,
persistent-nontransactional,
illegal
};
private static final int IS_PERSISTENT = 0;
private static final int IS_TRANSACTIONAL= 1;
private static final int IS_DIRTY= 2;
private static final int IS_NEW = 3;
private static final int IS_DELETED = 4;
private static final int NUM_STATUSES= 5;
/*
* This table indicates the values returned by the status interrogation
* methods for each state. This is used to determine the current lifecycle
* state of an object.
*/
private static final boolean state_statuses[][] = {
// IS_PERSISTENT IS_TRANSACTIONALIS_DIRTY IS_NEW
IS_DELETED
// transient
{ false, false, false, false, false},
// persistent-new
{ true, true, true, true, false},
// persistent-clean
{ true, true, false, false, false},
// persistent-dirty
{ true, true, true, false, false},
// hollow
{ true, false, false, false, false},
// transient-clean
{ false, true, false, false, false},
// transient-dirty
{ false, true, true, false, false},
// persistent-new-deleted
{ true, true, true, true, true},
// persistent-deleted
{ true, true, true, false, true},
