ObjectCacheDefaultImpl
Per default OJB use a shared reference based ObjectCache
implementation. It's a really fast cache but there are a few drawbacks.
There is no transaction isolation, when thread one modify an object,
thread two will see the modification when lookup the same object or use a reference
of the same object.
If you rollback/abort a transaction the corrupted objects will not
be removed from the cache (when using PB-api, top-level api may support
automatic cache synchronization). You have to do this using
 |  |  |
 |
broker.removeFromCache(obj);
// or (using Identity object)
ObjectCache cache = broker.serviceObjectCache();
cache.remove(oid);
|  |
 |  |  |
by your own or enable the useAutoSync property (more info see below).
This implementation use SoftReference
to wrap
all cached objects. If the cached object was not longer referenced by your application
but only by the cache, it can be reclaimed by the garbage collector.
As we don't know when the garbage collector reclaims the freed objects, it is
possible to set a timeout
property. So an cached object was
only returned from cache if it was not garbage collected and was not timed out.
To enable this ObjectCache
implementation
 |  |  |
 |
<object-cache class="org.apache.ojb.broker.cache.ObjectCacheDefaultImpl">
<attribute attribute-name="timeout" attribute-value="600"/>
</object-cache>
|  |
 |  |  |
Implementation configuration properties:
Property Key |
Property Values |
timeout |
Lifetime of the cached objects in seconds.
If expired, the cached object was discarded - default was 900 sec.
When set to -1 the lifetime of the cached object depends only on GC
and do never get timed out.
|
autoSync |
If set true all cached/looked up objects within a PB-transaction are traced.
If the the PB-transaction was aborted all traced objects will be removed from
cache. Default is false.
NOTE: This does not prevent "dirty-reads" by concurrent threads (more info see above).
It's not a smart solution for keeping cache in sync with DB but should do the job
in most cases.
E.g. if you lookup 1000 objects within a transaction and modify one object and then abort the
transaction, 1000 objects will be passed to cache, 1000 objects will be traced and
all 1000 objects will be removed from cache. If you read these objects without tx or
in a former tx and then modify one object in a tx and abort the tx, only one object was
traced/removed.
|
Recommendation:
If you take care of cache synchronization and be aware of dirty
reads, this implementation is useful for read-only or less update
centric classes.
ObjectCachePerBrokerImpl
This local cache implementation allows to have dedicated caches per PersistenceBroker instance.
All calls are delegated to the cache associated with the current broker instance.
When the broker
- does commit a transaction
- does abort/rollback a transaction
- was closed (returned to pool)
the cache was cleared. So no dirty reads will occur, because each thread use it's own PersistenceBroker
instance. No corrupted objects will be found in cache, because the cache was cleared after use.
ObjectCacheJCSImpl
A shared ObjectCache
implementation using a JCS region for
each classname. More info see
turbine-JCS.
ObjectCacheEmptyImpl
This is an 'empty' ObjectCache implementation.
Useful when caching was not desired.
NOTE: This implementaion does not support circular References.
Be careful when using this implementaion with references (this may change in
further versions).
ObjectCacheOSCacheImpl
A implementation using OpenSymphony's OSCache. More
info see here.
Additional ObjectCache implementations can be found in
org.apache.ojb.broker.cache package.