openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ravi Palacherla <ravi.palache...@oracle.com>
Subject Re: L1 and L2cache.
Date Mon, 14 Nov 2011 18:29:15 GMT
Yes it may not be a bug, but will it not be nice to have a feature like this in openJPA ?

Especially when a deleted entity ( deleted by other EntityManager) is being recognized by
other entitymanagers ( even though this entity is in L1cache)
Will it not be nice for updated entities ( updated by other EntityManager) to reflect the
change in L1cache of other EMs , especially when user is choosing to go to the DB for queries(
by disabling query cache) ?

Regards,
Ravi.

On Nov 14, 2011, at 10:37 AM, Kevin Sutter wrote:

> I don't consider it a bug.  That's the nature of optimistic locking.
> Unless you clear or refresh the caches you are working with, there is the
> risk of accessing stale data due to other transactional activity against
> the database.
> 
> Kevin
> 
> On Mon, Nov 14, 2011 at 11:23 AM, Ravi Palacherla <
> ravi.palacherla@oracle.com> wrote:
> 
>> Hi Kevin,
>> 
>> In my case the queries are going to the database as I disabled query cache.
>> The problem is after the query is executed, it still returns the old
>> values based on the values in L1cache.
>> I dont think the IgnoreChanges value is going to effect the L1cache.
>> 
>> For deleted rows I am not getting old values from L1cache but the problem
>> is only for updated rows where the updated values are not reflected in the
>> L1cache.
>> So can this be considered a bug where when a query is executed against
>> database it is supposed to change the L1cache values(in case of stale data
>> in cache) ?
>> 
>> Regards,
>> Ravi.
>> 
>> On Nov 14, 2011, at 9:36 AM, Kevin Sutter wrote:
>> 
>>> Hi Ravi,
>>> There are a couple of properties that sort of relate to what you are
>>> requesting.  These are the IgnoreChanges and FlushBeforeQueries
>> properties
>>> as documented here:
>>> 
>> http://openjpa.apache.org/builds/apache-openjpa-1.2.3-SNAPSHOT/docs/manual/manual.html#ref_guide_dbsetup_retain
>>> 
>>> Although these properties pertain to your current transactional state (vs
>>> other transactional state), they still may do the trick with forcing the
>>> queries against the database instead of performing an in-memory query.
>>> Specifically, you might want to try setting IgnoreChanges to true
>> (default
>>> is false).
>>> 
>>> Other than that, I think you have to resort to the programmatic approach
>> of
>>> clearing or refreshing the state of the entities.
>>> 
>>> Good luck,
>>> Kevin
>>> 
>>> On Mon, Nov 14, 2011 at 9:32 AM, Ravi P Palacherla <
>>> ravi.palacherla@oracle.com> wrote:
>>> 
>>>> EM2's persistence context is not closed and it is executing the queries
>>>> outside transaction.
>>>> 
>>>> The entity still exists in L1 cache and hence the old values are shown.
>> How
>>>> to clear the L1cache ?
>>>> I think there are ways like, entityManager.clear() or refresh() or
>> evict()
>>>> or using new entityManager.
>>>> But all of these are programatic approaches where there is a chance that
>>>> most of the times the data is not changed by EM1 but I still end up
>>>> clearing
>>>> EM2's cache.
>>>> 
>>>> So is there a way I can tell openJPA , when a query is executed, to
>> verify
>>>> if the objects in L1cache are out of sync with L2cache (or when a query
>>>> goes
>>>> to datasource and L1cache values are different from the one's in
>>>> datasource)
>>>> and if they are different then update the L1cache with values of
>> L2cache or
>>>> datasource ?
>>>> 
>>>> --
>>>> View this message in context:
>>>> 
>> http://openjpa.208410.n2.nabble.com/L1-and-L2cache-tp6980197p6992870.html
>>>> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>>>> 
>> 
>> 


Mime
View raw message