[infinispan-dev] stale persisted data?

[Sanne Grinovero]

As discussed on IRC - but repeating here for the sake of others: the
testsuite needs to guarantee it cleanups properly all different
storage points after each test execution (both in case of success and
failure).
You have three, so make sure you're not forgetting one:
 - Lucene Indexes
 - Caches (in memory / clustered)
 - Any CacheLoader(S). Including the Filesystem CacheLoaders that AS7
might be enabling without you know.

Cheers,
Sanne

On 11 May 2012 14:56, Scott Marlow <smarlow at redhat.com> wrote:
> 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
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev