> Shouldn't that JPA delete in finally block clean all stale
data?
I assume you mean from the first test run. In the second test run that fails, we
won't hit the finally block (since the run() method is throwing an exception before we
hit the try block).
Yes.
The "deleted" data is still there after 1st run,
hence breaking 2nd run.
>
> Trying to reproduce this now with smaller dep chain. :-)
>
> ---
Does this method run in an active JTA transaction? I assume yes but wanted to verify
(could also be using an extended persistence context for all I know ;).
What else is the run() doing? Does it run the passed EMAction in a different thread? I
hope not, since the EM is not thread safe.
Finally, the finally block should be changed to use em.remove(entity), since the current
code will not find the row that your trying to delete (the entity probably didn't get
written to the database yet since the JTA tx is still active).
The tx are fine. ;-)
This is a completely diff JPA beast.
It's not Hibernate or even OGM, is the JPA you know running in GAE.
That's why I mention the complex chain:
JPA impl in this case is GAE's extension for DataNucleus,
which delegates to DataNucleus' JDO, which delegates to GAE's JDO plugin,
which then uses GAE' DatastoreService, where in GAE's case delegates to BigTable,
but in our - CapeDwarf - case it delegates to Infinispan Query.
I'll try to drill down on why the data is not deleted / removed from FS.
Any ideas welcome.
-Ales