openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Logemann ...@logemann.org>
Subject Re: Data + Query cache
Date Fri, 25 Aug 2006 14:03:42 GMT
Is there a way to query OpenJPA if the result came from the cache? Or  
are partial cache results possible, thus making such a isCached()  
method impossible to implement.

--
regards
Marc Logemann
[blog] http://www.logemann.org
[busn] http://www.logentis.de


Am 25.08.2006 um 14:39 schrieb Kevin Sutter:

> Abe,
> In general, I wouldn't mind having the level 2 caches turned on by  
> default.
> My concern is that we don't want first time users to get unexpected
> results.  Like you mentioned in your previous reply, if we select the
> appropriate default values for the caches so that we can most  
> likely avoid
> stale reads, but still help with general performance, then I'm okay  
> with the
> idea.  But, if these caches cause our users to question the results or
> require them to tweak the cache settings for their first  
> applications, then
> I would prefer to go the safe route and leave the caches turned off by
> default.
>
> All that I know about these caches at this point is what you have  
> documented
> in your OpenJPA manual, so I don't have much personal experience  
> with them.
>
> The goal should be to have a pleasant first-time experience with  
> OpenJPA.
> :-)
>
> Kevin
>
> On 8/24/06, Abe White <awhite@bea.com> wrote:
>>
>> > t I was looking for some documentation about what the default cache
>> > configuration settings would be, and I'm not seeing it there.
>>
>> The defaults are:
>> - Data cache maintains hard refs to 1000 PCData object, where a
>> PCData holds the cached data for a single persistence-capable object.
>> - When the 1000 object limit is exceeded, we move random objects to a
>> soft backing map.  This map does not have a size limit, other than
>> what the JVM decides to GC.  The reason we evict randomly is that LRU
>> eviction requires more synchronization.
>> - Query cache has the same defaults (1000 hard refs, soft backing
>> map), but each entry is a list of oids for matching objects, or
>> object/object[] in the case of projections.
>>
>> All this is user-configurable, of course.
>>
>> > 1) How much memory would the default 'cache on' setting consume?
>> > Are people going to easily receive OOM errors with the default
>> > settings?  (I doubt it, but thought it should be mentioned.)
>>
>> The above defaults shouldn't cause OOM errors in most JVMs.
>>
>> > 2) What's the default concurrency strategy?  My wife and I making
>> > an ATM withdrawal or deposit at the same time makes me nervous the
>> > farther away from transactional we get.
>>
>> We bypass the cache during non-optimistic transactions, so DB locking
>> isn't affected.  And the standard optimistic checks ensure data
>> integrity in non-optimistic transactions.  If you start using the
>> cache in a distributed environment or among multiple
>> EntityManagerFactories you have to consider possible stale reads if
>> the cache invalidation notification from one EMF hasn't reached the
>> others yet, but that's not the common case.
>>
>> _____________________________________________________________________ 
>> __
>> Notice:  This email message, together with any attachments, may  
>> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
>> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted   
>> and/or
>> legally privileged, and is intended solely for the use of the  
>> individual
>> or entity named in this message. If you are not the intended  
>> recipient,
>> and have received this message in error, please immediately return  
>> this
>> by email and then delete it.
>>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message