DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to.
DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued

On a fresh MySQL 5.5.11 database without any schema defined a certain Model can cause that the first javax.jdo.Transaction.commit() hangs when datanucleus.autoCreateSchema is set to true.
Be aware that this happens only on an empty database. In case this test hangs and gets killed and restarted it works as part of the schema
is already defined.

Andy Jefferson added a comment - 13/May/11 02:22 PM There are many RDBMS that "hang" on such cases since the connection has already been used for INSERT on the table in question, and hence why we always have recommended using SchemaTool before usage.
I don't see what DataNucleus can reasonably do here other than what it is doing ... encounters A, so creates TABLE_A, encounters B, so tries to update TABLE_A for what B requires.

But in my case it hangs when i create the first instance of A.
Is there not the order of the sql statements wrong ?
First do any table updates and than any instance inserts ?
----------------
Properties properties = new Properties();
try {
properties.load(new FileInputStream("datanucleus.properties"));
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}

Witn regards to changing how DataNucleus does things, well as you well know JDO does not define a mechanism for saying "this list of classes are all that i am persisting". Consequently DataNucleus cannot know about all possible subclasses of class A. In fact there may have been another subclass in some other package.jdo file (or with annotations) that was only encountered later in that transaction. This means that the only reliable way of handling the situation is for the user to use persistence.xml and define all classes in it, and then set a persistence property to load all classes into the StoreManager at startup (look in the docs). This would then generate all schema before any such transaction.

As a result, issues like this will always remain low priority since Mr User has ample workarounds, and I haven't got infinite time ;-)

Andy Jefferson added a comment - 13/May/11 02:52 PM Witn regards to changing how DataNucleus does things, well as you well know JDO does not define a mechanism for saying "this list of classes are all that i am persisting". Consequently DataNucleus cannot know about all possible subclasses of class A. In fact there may have been another subclass in some other package.jdo file (or with annotations) that was only encountered later in that transaction. This means that the only reliable way of handling the situation is for the user to use persistence.xml and define all classes in it, and then set a persistence property to load all classes into the StoreManager at startup (look in the docs). This would then generate all schema before any such transaction.
As a result, issues like this will always remain low priority since Mr User has ample workarounds, and I haven't got infinite time ;-)

The provided testcase hangs after sending an INSERT and then needing to do a schema update, due to the user not notifying the persistence process of classes that are present.

The simple workaround of putting annotated classes and mapping files into persistence.xml, and using persistence property "datanucleus.PersistenceUnitLoadClasses" as true works fine on all cases present here (including this)

Andy Jefferson added a comment - 14/Sep/11 08:04 PM The provided testcase hangs after sending an INSERT and then needing to do a schema update, due to the user not notifying the persistence process of classes that are present.
The simple workaround of putting annotated classes and mapping files into persistence.xml, and using persistence property "datanucleus.PersistenceUnitLoadClasses" as true works fine on all cases present here (including this)