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

[Laird Nelson <ljnelson@xxxxxxxxx>]

Thank you; I was hoping there would be some ugly static method somewhere that wouldn't require an entity manager to do its work (I'd rather have this cache clearing behavior happen "outside" of the embedded Glassfish installation rather than from a bean inside it), but I think I can make all this work.  Thanks for the help.

Best,
Laird

On Wed, Sep 28, 2011 at 8:33 AM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:

Starting in JPA 2.0, there are some standardized cache methods on EntityManagerFactory.  You can call entityManagerFactory.getCache().evictAll().

If you do not have a reference to the EntityManagerFactory, you can use our JpaHelper class to get it.

JpaHelper.getEntityManagerFactory(entityManager)

-Tom

Phillip Ross wrote:

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

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

-- 
http://about.me/lairdnelson