On 05/11/2012 09:20 AM, Ales Justin wrote: >>> 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. I see, but my way would be more portable. It would of been nice if the fix was this easy. :)
> > -Ales > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
