CoexistenceWithOtherApplications

How well can a Toplink application co-exist with another non-Toplink application accessing the same database? Are there ways to avoid the Toplink cache from becoming out of sync with the database if another application is also accessing some of the same tables? Are there any good methods for dealing with this? forum:268014

It is very common for TopLink applications to co-exist with pre-existing or other application written using different technologies. This does lead to issues when configuring the cache and queries to minimize stale-cache.

The first thing you MUST do is settle on a concurrency locking model. Typically this is done using optimistic locking but can also be accomplished with pessimistic locking. The former is recommended for user interactive applications. I would recommend using a single version column on each table (if possible) and allow TopLink to track the versioning to ensure you never make a write based on stale data (directly or via related data).

Now that you have protected your data you need to configure the cache and queries relative to how the various applications modify data. TopLink allows you to configure the cache on a per type basis so you need to categorize each type in your model:

READ-ONLY: FullIdentityMap, no worries of stale data. If the volume of instances is large you may want to consider SoftCacheWeakIdentity? map to maintain the last N used objects.

TRANSACTIONAL: WeakIdentityMap. These are the types that change frequently or are only ever used by a single user at a given time period. This will cause you to only keep them in cache while they are being used.

READ-MOSTLY: These are the most difficult as it is hard to know whether it is better to refresh each time or trust the cache object and handle the optimistic lock failure with a refresh. It is these types that truly benefit from cache synchronization. For these I would typically use a SoftCacheWeakIdentityMap? with a reasonable size for the number of concurrent instances that may be in use.

For this last case and occasionally for the TRANSACTIONAL types it may be best to also force the refresh at the start of important operations. This can be done using refreshIdentityMapResult() on the query. This also can be further optimized with onlyRefreshIfNewerVersion(), which can short circuit the refresh if the version in the database matches the version field in the cached object.

In all cases the database is the true source of truth. Transactions on the database using optimistic locking will guarantee you don't corrupt you data and the various cache configurations and cache coordination options are intended to reduce the chance of stale data being used. Make sure you code you transactions to handle optimistic lock failures.

The above is typically all you need to do to handle the case described but we do have customers who go beyond this. For some applications their read-mostly data changes so infrequently but is so critical to be accurate that they implement mechanisms to invalidate the cache via messages from the database. This can be done using triggers -> AQ -> JMS.

Note: In TopLink 10.1.3 you will be able to invalidate objects programmatically or via expiration time configurations.

See Also