I'm trying to implement a persistence layer and get stuck without being able to understand why.

I'm using Eclipselink 2.3.0 and try to write on a MySQL DB (I got the same proble when I tried on Derby, so *I suppose the DB doesn't matter), with the Eclipselink drop-and-create-tables option in the persistence.xml.

I thought it could be qomething related to cache, googled and found some things like this for example :

<shared-cache-mode>NONE</shared-cache-mode>

And some variants that I tried in my persistence.xml, but nothing worked. The tests run fine once in a while, without any apparent reason. For example, they can pass just after a minor modification of the persistence.xml, but fail if I try to run them again. And the opposite happens, too.

This kind of problem didn't happen when I used Eclipselink 1.1.0. But it happens with every Eclipselink 2.x.

This appears to be a DDL generation issue and has nothing to do with Cache settings. Is there an error raised when the 'PROJECT' table is dropped? Are you adding mappings between re-deployments? The Tables are dropped based on the current structure of the Persistence Unit not the structure of the previous deployment. It is possible the drop is failing because you have changed the mapping or the classes in the Persistence Unit and the drop of a related table is missing and the 'PROJECT' table then fails to drop.

The properties in the persistence.xml file suggest you are generating scripts. You may want to use the drop script from the previous deployment to remove the tables.

This appears to be a DDL generation issue and has nothing to do with Cache settings. Is there an error raised when the 'PROJECT' table is dropped? Are you adding mappings between re-deployments? The Tables are dropped based on the current structure of the Persistence Unit not the structure of the previous deployment. It is possible the drop is failing because you have changed the mapping or the classes in the Persistence Unit and the drop of a related table is missing and the 'PROJECT' table then fails to drop.

The properties in the persistence.xml file suggest you are generating scripts. You may want to use the drop script from the previous deployment to remove the tables.

From your description, it looks like the initial create table Project statement is succeeding with other statements occuring before another create table Project statement occurs again and fails. If so, then it is working - the table is being dropped and then recreated. The problem is that later on there is another create table project statement. This is only a warning that can be ignored, but feel free to file a bug if you can create a small test project that reproduces the issue to have the reason for the second create statement looked into - the smaller the test case the better.

The problem isn't that the table gets created once or twice, but that I try to insert test data (always the same from one test session to another), designed to never allow duplicate entries, and that those insertions work with eclipselink 1.2 (the tables get dropped, recreated, and data gets inserted without problem), but not with eclipselink 2.3.

Given the error messages, I thought at first that the DB didn't drop the tables, but as you say, it seems that they're dropped fine, but recreated twice. So is it possible that the test data gets inserted twice too, thus the integrity constraint violation ?

I haven't looked further lately, but I will, and try to submit runnable short tests illustrating this.

The problem isn't that the table gets created once or twice, but that I try to insert test data (always the same from one test session to another), designed to never allow duplicate entries, and that those insertions work with eclipselink 1.2 (the tables get dropped, recreated, and data gets inserted without problem), but not with eclipselink 2.3.

Given the error messages, I thought at first that the DB didn't drop the tables, but as you say, it seems that they're dropped fine, but recreated twice. So is it possible that the test data gets inserted twice too, thus the integrity constraint violation ?

I haven't looked further lately, but I will, and try to submit runnable short tests illustrating this.