I'm looking at improving the performance of our integration tests.
We have some EJBs with injected persistence contexts in them.
At the moment, because of EclipseLink session cache issues, we bring up and
destroy an instance of embedded Glassfish in between each *test*, not just
in between each test *suite*.
As you might imagine, the performance is horrible.
(If instead we bring embedded Glassfish up, run a test suite, and then take
embedded Glassfish down, then the session cache has some results in it that
last between integration tests. For a variety of reasons we don't want
this to be the case.)
(We also don't want to turn off the session cache, as some of our tests are
designed to make sure that it is working.)
(Fun mess, huh?)
The general line of attack I had in mind was to deploy a test EJB alongside
our other EJBs that--when appropriately called--could somehow grab ahold of
the proper EntityManagerFactory, invoke its getCache() method, and then
invoke evictAll(). The test harness would ensure that this "cache cleaner"
EJB would be called in between individual tests.
However, a persistence context is defined by the specification as existing
in the java:comp/env namespace, and the comp/env namespace is per-component
(so in this case per-EJB). This means that at least according to the
specification that having EJB #2 try to look up EJB #1's persistence
context using JNDI is not likely to work.
Having said that, EJB #2 (the cache cleaner EJB) would only actually need a
handle on the EntityManagerFactory, so perhaps there's some other way to
get ahold of that.
Does anyone have any further ideas here? Or, equally helpfully, some
reason for why this is an idiotic thing to try to do? :-)
Thanks,
Laird
--
http://about.me/lairdnelson