How to deal with this problem?

Question

How to deal with this problem?
We plan to use Oracle Coherence (In Memory Data Grid) for a large-scale application. In order to keep the database table data in Coherence caches, we will create all the corresplonding Java objects (entities) and construct the persistence system using JPA/EclipseLink+JDBC. In this way, any in-memory object update will be persisted to the corresponding database tables.
The problem is that some existing application codes are updating these database tables directly now. If the direct-database-table update is not permmited in the persistence environment, we have to discard most of the existing application scripts.
I want to know, in this situation, should I discard most of the existing scripts?
Are there any other solutions?

Answer 1

Allowing writes from both cache & DB is possible with its own set of issues.
The main issue to consider is conflicts from updates on same record via both cache and DB. If your caches are write-through the conflict decreases - but then cache writes become slower. If your caches are write-behind potentially the older cache update will overwrite the latest DB update. Now you are back to Database 101 -- timestamps, versions, etc...
If you use a DB trigger to initiate the resync request you might want to distinguish whether the update has come from the cache-store (in which case, you may choose to do nothing), or if the update was from the 'existing apps', etc...
If you choose to inject the resync logic at the application code level - you have the usual sourcecode issues - can you modify the code, is all the DB code localized, what options do you have to link with Coherence functionality (DLL, external proc, webservice, etc), etc... Naturally though, if you have to make substantial changes to signal a resync....you might consider taking the extra step and change the code to write to the cache.