On Tue, Sep 27, 2011 at 6:40 PM, Laird Nelson
<ljnelson@xxxxxxxxx> wrote:
I'm seeing something very odd and I want to run a theory by the EclipseLink folks.
I wanted to make a couple of corrections.
My setup is as follows:
- Test class is created.
- H2 in memory database is created and set to not shut down until the VM does.
- For each test method:
- Liquibase (www.liquibase.org) sets up the schema and its tables if it doesn't exist.
- DbUnit (www.dbunit.org) comes in and sets up the test data, blowing the contents of the tables away first.
- A new instance of embedded glassfish is started (running EclipseLink 2.2.0).
This turns out to be incorrect. The new instance of embedded Glassfish is started after the initial step 2. This means that it is possible that an EclipseLink second level cache might be living across stateless session bean invocations, probably by design.
Is there any static way to invalidate the second level cache? Or some other outside-of-embedded-Glassfish way to notify the embedded EclipseLink provider that the second level cache needs to be blown up? I suppose I could even deploy some dubious hacky EJB that when invoked does it from an injected @PersistenceContext or @PersistenceUnit. Any suggestions are welcome here.
Again, I am trying to achieve isolation between test methods.
Best,
Laird
