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 < > [email protected]> 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 < >>> [email protected]> 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. >>>> >> >>
