Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] Race conditions in EclipseLink runtime?

This is an odd one and I could use some advice on how to narrow it down further.

The background: I have an AbstractJPATestCase (a JUnit test case) that:
* Runs once for each of the "big three" JPA providers (via the
* Creates a new EntityManagerFactory for each one (I have a
persistence.xml file located in my Mavenized project under the
src/test/resources/META-INF directory, with three Java SE resource
local persistence units defined: one for OpenJPA, one for EclipseLInk
and one for Hibernate; all three are identical except for
provider-specific logging settings)
* Asks the factory for a new EntityManager for each one
* Begins a transaction
* Runs the actual body of the test (the test method the subclass defines)
* Commits the transaction (this is all on top of the H2 database)
* Closes the EntityManager and EntityManagerFactory machinery.

Usually the subclass simply does something like a simple insert and
retrieval, just to smoke test my entity mappings.

I've noticed for one particular setup involving @OneToMany Map
mappings that EclipseLink sometimes succeeds and sometimes fails, with
no changes in my code.  It appears to fail the build around 20% of the
time and succeed all the others.  That is, if I simply rerun the build
(mvn clean install) five times in a row, I'm likely to encounter one
failure for every four successes or so.  Again, EclipseLink is the
only one that ever fails here.

I'd like to open up this dialogue with a general question: is there
any obvious place within the EclipseLink runtime where new threads are
spawned, or where concurrency might be an issue?  This exhibits all
the symptoms of a race condition.

My next step will be to try to disentangle my setup in such a way that
I can send a test case.

If it helps, I am treating EclipseLink 2.0.1 as just another JPA
provider; i.e. I'm not using any EclipseLink-specific features.


Back to the top