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 <[EMAIL PROTECTED]> 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.
