Good summary. No worries on posting to dev, this is the perfect list
for this kind of discussion.
Give the unique test DB name trick a try and see if that doesn't get
you a new in-memory db for each test.
-David
On Aug 17, 2009, at 10:42 AM, Laird Nelson wrote:
After some back-and-forthing with David (thanks, David!) and some
external
links, I'm to a point where I need to request more help from the
OpenEJB
team.
The background: I am invoking OpenEJB through the Maven SureFire
plugin and
running it as part of my JUnit 4.6 unit tests. I'm using H2 for my
database. I need to wipe out the H2 database between each @Test run.
Here's where I am:
- SureFire, no matter how you configure it, will not fork a new
JVM for
each @Test method. It *will* fork a new JVM for each test
*class*, but
that isn't good enough for what I'm doing. So simply using the
Surefire forkMode
set to "always" isn't going to work.
- To preserve test isolation, I need to make sure that the
OpenEJB local
InitialContext is actually destroyed when it is closed. For this
I am using
the excellent tip in
http://blog.jonasbandi.net/2009/06/restarting-embedded-openejb-container.html
.
However, this solution--while it restarts the context just fine
(huzzah!)--does not appear to nuke the H2 database, nor does it
cause the
creation of a new EntityManagerFactory under the covers. This
last part is
a supposition on my part--the symptom I'm seeing is that the
automatic DDL
generation I have configured only runs once, where I want it
instead to run
before each @Test. The net result is that I get primary key
violations
because data inserted as part of test method 1 is seen by test
method 2,
which expects an empty database.
- H2 keeps an in-memory database open and populated as long as
there is
at least one connection hooked up to it. I can state with
certainty that
the fact that the database is still up and populated when test
method #2
runs is evidence of the fact that at least one connection to the
H2 database
survives a container restart.
What I need is a way to not just restart the OpenEJB container but the
OpenJPA instance it controls as well. As far as I can tell, this is
not
restarted when the context is closed/destroyed. I see three
fundamental
approaches here:
1. Treat the fact that the JPA subsystem is not restarted as a
bug, and
"fix" it so that when you specify that the context should be
destroyed the
whole shooting match goes down.
2. Invoke some unknown-by-me method that will restart the JPA
internals.
3. Hack on Surefire or JUnit in some way to provide an option for
forking
a VM for each test method and ignore the fact that OpenEJB for
whatever
reason doesn't cause the OpenJPA internals to restart.
Any further tips here are welcomed and appreciated.
It also occurs to me this is a conversation for the dev list, but I
figured
that enough users out there are doing this sort of thing that
someone may
have solved this problem.
Best,
Laird
