[
https://issues.apache.org/jira/browse/OPENJPA-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated OPENJPA-1150:
----------------------------------
Affects Version/s: (was: 2.0.0)
2.0.0-M2
Fix Version/s: (was: 2.0.0)
2.0.0-M3
> Add WriteBehind mode to cache updates before flushing to backing store
> ----------------------------------------------------------------------
>
> Key: OPENJPA-1150
> URL: https://issues.apache.org/jira/browse/OPENJPA-1150
> Project: OpenJPA
> Issue Type: New Feature
> Components: kernel
> Affects Versions: 2.0.0-M2
> Reporter: Michael Dick
> Assignee: Michael Dick
> Fix For: 2.0.0-M3
>
>
> The current L2 / DataCache implementation is exhibits write-through behavior.
> When an entity is updated its contents are updated in the datacache and then
> flushed to the backing store when the transaction completes.
> This feature will enable write-behind behavior - instead of updating the
> backing store when the transaction completes, the updates will be cached in
> memory until until triggered to truly flush. This approach has the effect of
> reducing the load on the backing store and (hopefully) improving overall
> throughput.
> Naturally there are some caveats to this approach.
> 1. A DataCache must be used in conjunction with the WriteBehind cache. The
> DataCache will be kept in sync with the WriteBehind cache reducing the
> possibility of stale reads.
> 2. When operating in write-behind mode you need to take care that OpenJPA is
> the only application accessing these rows. Updates from other applications
> may lead to errors when the write-behind cache is flushed.
> 2a. Some care must be taken when running on multiple JVMs. The DataCache &
> WriteBehindCache need to be kept in sync across JVMs. The DataCache has some
> capability in this area and the WriteBehindCache will further extend that.
> 2b. The application must contain some logic to recover from a failed update.
> 3. Database generated columns (ie IDENTITY, SEQUENCE) will not work correctly
> (at least not with the initial version of write-behind)
> 3a. Table generated columns will work, but the SQL used to obtain the value
> from the table will bypass the WriteBehindCache (ie you may see some database
> traffic in this case).
> This support may not be suitable for every application. Write heavy
> applications will see great benefit as will applications which place high
> load on the database. The feature should not be enabled by default and should
> be considered strictly optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
