I'm trying to test a Glassfish hosted web application which calls various EJBs that in turn use the Eclipselink JPA implementation as the persistence layer. In my pre-test setup method, I'm using JDBC native queries to clear out the tables in my database so that each test will run with a clean database.
I then have a JUnit test case that is designed to run standalone and access the app using an HTTP client and everything's working great...the first time around. The issue is the second run as on the server, I can see records being retrieved (presumably from Eclipselink's cache) that aren't in the database (which I can see has been cleared out by the "setUp" JDBC calls mentioned earlier).
I've tried turning the cache off in the persistence.xml descriptor by setting eclipselink.cache.type.default to NONE, which caused stack overflow errors and I've also tried reducing the size of the cache to 0 in an attempt to force the cache to refresh all objects from the data store but it doesn't help unfortunately.
I was wondering how people tested remotely in this manner?
Many thanks for reading this post,
Joined: Feb 24, 2009
I'm now happily running integration tests with repeatable results from a standalone JUnit application, calling through a JAX-RS view layer using HTTP into an EJB3 business logic layer which in turn is using the EclipseLink JPA data layer.
My original problem was that I want to use functionality in the test code that I don't want to expose in the production code (such as wiping all data from the database etc.). Using JDBC from JUnit (which can't directly use my JTA configured Persistence Units), I was able to do all of the nasty things required for my tests to behave consistently. Unfortunately, EclipseLink's cache was becoming stale due to my outside tinkering through JDBC.
My test harness now performs the following actions before each test:
Clear out each table in the database using JDBC
Call an application one-time-only "setup" resource that in turn calls through to an EJB business method that invalidates all EclipseLink cache for the server
Perform any per-test JDBC database bootstrapping
The call used to solve my particular problem of stale cached objects was made accessible by using EclipseLink's JpaHelper utility class to eventually get hold of an interface to the identity map, upon which I call invalidateAll() to invalidate all cached objects. The following code was added to the "setup" resource that ultimately initialises a newly deployed instance of the application by bootstrapping the database amongst other things:
Perhaps this'll be of some use for other people wondering how to invalidate the entire EclipseLink cache for a particular server.