[infinispan-dev] stale persisted data?
Scott Marlow
smarlow at redhat.com
Fri May 11 09:28:23 EDT 2012
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
>
More information about the infinispan-dev
mailing list