On 05/11/2012 09:28 AM, Scott Marlow wrote:
> 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.  :)

Even though it probably won't make a difference, what happens if you try 
it my way (just in case your fighting against an DataNucleus internal 
implementation detail unexpectedly).

>
>>
>> -Ales
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to