openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandros Karypidis <akary...@yahoo.gr>
Subject Re: Fetch database changes from external sources
Date Fri, 16 May 2008 07:10:31 GMT
Hello all,

I used the information provided to test the "DataCache" or "2nd-level" 
cache. The cache doesn't seem to be the problem.

I added the following to the persistence.xml:

	<property name="openjpa.DataCache" value="true" />
	<property name="openjpa.RemoteCommitProvider" value="sjvm"/>
	<property name="openjpa.QueryCache" value="true" />
	<property name="openjpa.Log"
		value="SQL=TRACE, DataCache=TRACE" />

I also tried with the cache disabled (value="false" for 
openjpa.DataCache) and in both cases refresh() does nothing.

With the cache enabled, a cache hit is logged. With the cache disabled, 
no DataCache logging channel messages are produced. In both cases, no 
SQL is executed to re-fetch the object.

Here is the log output with the cache DISABLED
===========================================================
937  testOpenJPA  TRACE  [main] openjpa.jdbc.SQL - <t 31365828, conn 
25345246> executing prepstmnt 9030750 SELECT t0.strField FROM Record t0 
WHERE t0.recId = ? [params=(int) 1]
937  testOpenJPA  TRACE  [main] openjpa.jdbc.SQL - <t 31365828, conn 
25345246> [0 ms] spent
RECORD 1 EXISTS, VALUE: Rec 1
PRESS ENTER TO REDISPLAY...
RECORD 1 EXISTS, VALUE: Rec 1
===========================================================


Here is the log output with the cache ENABLED
===========================================================
859  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache miss while 
looking up key "1".
922  testOpenJPA  TRACE  [main] openjpa.jdbc.SQL - <t 23860799, conn 
19432672> executing prepstmnt 5324129 SELECT t0.strField FROM Record t0 
WHERE t0.recId = ? [params=(int) 1]
922  testOpenJPA  TRACE  [main] openjpa.jdbc.SQL - <t 23860799, conn 
19432672> [0 ms] spent
937  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache miss while 
looking up key "1".
937  testOpenJPA  TRACE  [main] openjpa.DataCache - Put key "1" into cache.
937  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache hit while 
looking up key "1".
RECORD 1 EXISTS, VALUE: Rec 2
PRESS ENTER TO REDISPLAY...
6451  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache hit while 
looking up key "1".
6451  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache hit while 
looking up key "1".
6467  testOpenJPA  TRACE  [main] openjpa.DataCache - Cache hit while 
looking up key "1".
RECORD 1 EXISTS, VALUE: Rec 2
===========================================================

Drew Lethbridge wrote:

> Gday - They're talking about the DataCache.  Check out the docs here:
> 
> http://openjpa.apache.org/docs/latest/manual/ref_guide_caching.html
> 
> In your scenario, you might want to disable the datacache, or employ 
> datacache timeouts or eviction.
> 
> cheers!
> 
> ..droo.
> 
> On 15/05/2008, at 8:52 PM, Alexandros Karypidis wrote:
> 
>> Hi,
>>
>> First of all, thanks for the input.
>>
>> 1) I am not sure what the second-level cache is. Going through the 
>> user manual and searching the web did not help. All I could find that 
>> is cache-related are the following properties, which I set as follows 
>> (hoping that they indeed control the "second-level cache"):
>>
>>     <property name="openjpa.DataCache" value="false"/>
>>     <property name="openjpa.QueryCache" value="false"/>
>>
>>
>> 2) As far as calling evict is concerned, I added these calls between 
>> the two find() calls:
>>
>>     OpenJPAEntityManagerFactory jemFactory =
>>         (OpenJPAEntityManagerFactory) emFactory;
>>     jemFactory.getQueryResultCache().evictAll();
>>     jemFactory.getStoreCache().evictAll();
>>     
>>     OpenJPAEntityManager jem = (OpenJPAEntityManager) em;
>>     jem.evictAll(Record.class);
>>
>> Neither modification helped and as far as the second approach is 
>> concerned, I would prefer to restrict my code to standard JPA only.
>>
>> In any case OpenJPA still uses some cache to return the object the 
>> second time around.
>>
>> Can you point me towards something more concrete regarding this 
>> "second level cache" and how to disable it? Is it perhaps referred to 
>> by some other name? I really couldn't find information when 
>> web-searching for stuff like "openjpa second level cache".
>>
>> Thanks again for your time.
>>
>> Craig L Russell wrote:
>>
>>> Hi,
>>> It sounds like you're using the second-level cache which is dutifully 
>>> returning the current contents that are cached.
>>> Have you tried using the evict methods of the second level cache, or 
>>> disabling it for the application?
>>> Craig
>>> On May 14, 2008, at 2:37 AM, Alexandros Karypidis wrote:
>>>> Hi,
>>>>
>>>> First of all, I've done research through the archives for the 
>>>> situation I am facing and found this:
>>>>
>>>> http://mail-archives.apache.org/mod_mbox/openjpa-users/200706.mbox/%3C7262f25e0706152022u4942a14dkec98e30b520350b7@mail.gmail.com%3E

>>>>
>>>>
>>>> I am facing the exact problem mentioned in that thread: I need to 
>>>> fetch an object several times from the database, whose columns are 
>>>> updated from another program and pick up the changes made by that 
>>>> program. However, I can't get OpenJPA to re-execute SQL and retrieve 
>>>> the object's new data from the database.
>>>>
>>>> In the thread of the link I provide, I was lead to believe that 
>>>> em.refresh(obj) should do the trick. However, OpenJPA does not 
>>>> execute any SQL (I have SQL=TRACE in the log options and I only see 
>>>> one select statement) and keeps the old data in the object.
>>>>
>>>> I use OpenJPA release 1.0.2 and the code snippet with which I test 
>>>> is the following:
>>>>
>>>> =========================================================
>>>> EntityManagerFactory emFactory =
>>>>    Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
>>>> EntityManager em = emFactory.createEntityManager();
>>>>
>>>> Record r = em.find(Record.class, 1);
>>>> System.out.println("VALUE: " + r.getStrField());
>>>>
>>>> System.out.print("PRESS ENTER TO REDISPLAY...");
>>>> BufferedReader stdin = new BufferedReader(new InputStreamReader(
>>>>        System.in));
>>>> stdin.readLine();
>>>>
>>>> // ------> PROBLEM AREA <------
>>>> em.refresh(r); // does not work
>>>> // ((OpenJPAEntityManager)em).evict(r); // also does not work
>>>> // em.clear(); // works but detaches everything
>>>> // em.close(); // ... re-create. works, costs too much
>>>> // ------> PROBLEM AREA <------
>>>>
>>>> r = em.find(Record.class, 1);
>>>> System.out.println("VALUE: " + r.getStrField());
>>>> =========================================================
>>>>
>>>> I change the strField of the "Record" object using a database editor 
>>>> before I press enter to re-fetch the value.
>>>>
>>>> So, my question is, why does OpenJPA ignore the call to refresh() if 
>>>> the object is still attached? I don't see it as reasonable to detach 
>>>> all objects just to pick up a change in the database. I figured it 
>>>> may be a transaction isolation issue, but then did the following 
>>>> test which also did not work:
>>>>
>>>> =========================================================
>>>> EntityManagerFactory emFactory =
>>>>    Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
>>>> EntityManager em = emFactory.createEntityManager();
>>>>
>>>> em.getTransaction().begin();
>>>> Record r = em.find(Record.class, 1);
>>>> System.out.println("VALUE: " + r.getStrField());
>>>> em.getTransaction().commit();
>>>>
>>>> System.out.print("PRESS ENTER TO REDISPLAY...");
>>>> BufferedReader stdin = new BufferedReader(new InputStreamReader(
>>>>        System.in));
>>>> stdin.readLine();
>>>>
>>>> em.getTransaction().begin();
>>>> r = em.find(Record.class, 1);
>>>> em.refresh(r);
>>>> em.getTransaction().commit();
>>>> System.out.println("VALUE: " + r.getStrField());
>>>> =========================================================
>>>>
>>>> So even when reading the object through 2 different transactions, I 
>>>> still can't get its data to be re-fetched...
>>>>
>>>> Funilly enough, if i call rollback() on the transaction, it does 
>>>> work! However, it seems too much of a kludge to base my solution on 
>>>> that...
>>>>
>>>> Thanks in advace to anyone who takes the time to help out.
>>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>> P.S. A good JDO? O, Gasp!
>>
>>
> 
> 


Mime
View raw message