[eclipselink-users] EclipseLink cache longevity in embedded Glassfish?

[Laird Nelson <ljnelson@xxxxxxxxx>]

I'm seeing something very odd and I want to run a theory by the EclipseLink folks.

I'm using embedded Glassfish to do some integration testing.

Right now, I'm getting OptimisticLockExceptions in cases where I'm not updating anything.

My setup is as follows:

1. Test class is created.
2. H2 in memory database is created and set to not shut down until the VM does.
3. For each test method:
1. Liquibase (www.liquibase.org) sets up the schema and its tables if it doesn't exist.
   
2. DbUnit (www.dbunit.org) comes in and sets up the test data, blowing the contents of the tables away first.
3. A new instance of embedded glassfish is started (running EclipseLink 2.2.0).
4. The test looks up an EJB from embedded Glassfish and uses that bean--which has an EntityManager injected into it by the EJB container--to do whatever it does.  All tests write only to those tables managed by DbUnit.
5. The embedded glassfish is stopped and destroyed.

What I'm observing is that at the beginning of each method there is indeed the expected data (as set up in (2) above).  So I am starting each test run with a properly set up database.

However, sometimes my bean (looked up from the new Glassfish (and hence new EclipseLink) machinery in step (4) above) will use its EntityManager (injected by Glassfish, not me) to find an object, and that object will have a non-zero (@Version) version number.  That is, it appears that EclipseLink has gone to the cache.

Something smells "static" in here.  Everything in my workflow above is clean, simple, and "new instancey".

Is there some weird way in which embedded Glassfish--a "real" Glassfish installation, just running in memory--would have a reference to some sort of static EclipseLink cache?

What else could explain the initial high version?

Thanks,
Laird

-- 
http://about.me/lairdnelson