Re: [eclipselink-users] EclipseLink cache longevity in embedded Glassfis

[Phillip Ross <phillip.w.g.ross@xxxxxxxxx>]

Hi Laird, if you have a reference to the entity manager, you can cast
it to eclipselink's jpa entity manager.  From there you can use
eclipselink specific methods to invalidate the entity maps.  This is a
method that I've used to effectively wipe the 2nd level cache:

public static void initializeIdentityMaps(EntityManager entityManager) {
        JpaEntityManager jpaEntityManager =
(JpaEntityManager)entityManager.getDelegate();
        Session activeSession = jpaEntityManager.getActiveSession();
        if (activeSession == null) {
            logger.error("active session was null.");
        }
        assert activeSession != null;
        IdentityMapAccessor identityMapAccessor =
activeSession.getIdentityMapAccessor();
        if (identityMapAccessor == null) {
            logger.error("identitymap accessor was null.");
        }
        assert identityMapAccessor != null;
        identityMapAccessor.initializeIdentityMaps() ;
    }

There might be a better way to do this that is prescribed by the
eclipselink guys, but this seems to work for me :)

Hope it helps!
- Phillip

On Tue, Sep 27, 2011 at 11:04 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:
> 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
>
> --
> http://about.me/lairdnelson
>
>
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>