Ticket #900 (closed defect: fixed)

Opened 9 months ago

Last modified 8 months ago

Make pub-app caches transaction aware

Reported by: ronald Assigned to: pradeep
Priority: critical Milestone: 0.9.0
Component: topaz Version: 0.8.3-SNAPSHOT
Keywords: Cc:
Blocking: Blocked By:

Description

The pub-app caches are currently not transaction aware, so if something gets rolled back the caches are not, leading to cache pollution.

We should probably create some wrapper around the caches to queue updates and to hook into the transaction commit/rollback via TransactionSynchronizationManager.registerSynchronization().

Dependency Graph

Change History

04/04/08 13:19:48 changed by ronald

  • owner deleted.

04/05/08 14:52:49 changed by amit

  • owner set to pradeep.
  • priority changed from unassigned to critical.
  • blocking changed.
  • blockedby changed.

Based on conversation with Rich, we believe this should be cleaned up now.

04/25/08 01:15:54 changed by pradeep

  • status changed from new to assigned.

05/01/08 18:26:17 changed by pradeep

(In [5575]) Added an Interceptor concept for OTM Sessions. This is similar to the Interceptor support provided by Hibernate.

This is to help Ambra resolve a number of tickets related to caching. Please see #900,#901,#829,#845,#861 (and may be more)

As part of this update, please note that the Transaction API has the following additions: 'isActive', 'wasCommitted' and 'wasRolledBack'.

05/01/08 19:18:38 changed by pradeep

(In [5576]) Basic infrastructure support for transactional cache updates and cache invalidations and also support for a journal context aware second-level cache (similar to Hibernate).

Addresses #900,#901,#829,#845,#861.

CacheManager? provides a READ_COMMITTED isolation level. Only cache that is managed by this CacheManager? now is the journal context aware object-cache for OTM. No changes to existing caches or cache-invalidations yet.

05/06/08 10:16:06 changed by pradeep

(In [5638]) Undo transaction related mods from r5575. No notice from OTM on transaction state changes. Apps can directly get that from JTA. (Also note that we might remove the local Transaction support completely from OTM and only support JTA transactions.)

So Ambra CacheManager? now registers a synchronization call-back directly from JTA. In addition there is now no assumption on the spring request-scope and transaction scope being the same. (I was being lazy - thanks Ronald)

Since we can't define them as spring transaction scoped beans (no such scope provider exist currently), the beans have been converted to singleton scope and the CacheManager? manages a transaction context internally for all the caches. (ugly but works).

Addresses #900, #901.

05/06/08 13:37:49 changed by pradeep

(In [5644]) Convert browse cache to transactional cache. Addresses #900.

05/06/08 13:56:16 changed by pradeep

(In [5645]) Converted userCache to a transactional cache. Addresses #900.

05/06/08 14:41:19 changed by pradeep

(In [5646]) Convert feedCache to the transactional cache. Addresses #900. (No txn operations yet. But may be with invalidations it could come up)

05/06/08 15:09:04 changed by pradeep

(In [5647]) Convert searchCache to use transactional cache. Addresses #900. (No txn usage. May be later with invalidations.)

05/07/08 09:11:03 changed by pradeep

(In [5656]) Convert articleAnnotationCache to transactional. Addresses #900.

05/09/08 03:03:41 changed by pradeep

(In [5689]) Convert journal and carrier cache into transactional cache. Also cache invalidations are based on change-listeners - instead of relying on manual notifications sprinkled all over.

As part of this change, Journal service has been split into three:

WARN: only tested on SingleBox? install.

Addresses #900, #901.

05/10/08 01:27:50 changed by pradeep

  • status changed from assigned to closed.
  • resolution set to fixed.

r5693 is the last of the changes. Now all caches (except XACML and permissions) are transaction aware. Closing this ticket.