All Packages from org.jboss.cache.invalidation.* to org.jboss.cache.tests.*

Home >> All >> org >> jboss >> cache

•

Package Samples:

• org.jboss.cache.invalidation.bridges
• org.jboss.cache.invalidation
• org.jboss.cache.invalidation.triggers
• org.jboss.cache.tests.transaction
• org.jboss.cache.tests.replicated
• org.jboss.cache.tests.misc
• org.jboss.cache.tests.lock
• org.jboss.cache.tests.loader
• org.jboss.cache.tests.eviction
• org.jboss.cache.tests.basic
• org.jboss.cache.tests.aop

Classes:

• InvalidationManagerMBean: Main service dealing with cache invalidation. While more than one instance may be running at the same time, most of the time, only one will be used. Each InvalidationManager (IM) gives access to a set of InvalidationGroup (IG). Each IG concerns a particular cache and links subscribers that listen for cache invalidations messages with cache invaliders that will create invalidation messages. Thus, to start, a given service will first ask for a specific IG to work with. This is an in-VM operation: each cache and invalider works with a *locally* bound IM. If you want to extend the in-VM mode of operation, ...
• ReadWriteLockWithUpgradeTest: NonBlockingWriterLock is a read/write lock (with upgrade) that has non-blocking write lock acquisition on existing read lock(s). Note that the write lock is exclusive among write locks, e.g., only one write lock can be granted at one time, but the write lock is independent of the read locks. For example, a read lock to be acquired will be blocked if there is existing write lock, but will not be blocked if there are mutiple read locks already granted to other owners. On the other hand, a write lock can be acquired as long as there is no existing write lock, regardless how many read locks have been ...
• NonBlockingWriterLockTest: NonBlockingWriterLock is a read/write lock (with upgrade) that has non-blocking write lock acquisition on existing read lock(s). Note that the write lock is exclusive among write locks, e.g., only one write lock can be granted at one time, but the write lock is independent of the read locks. For example, a read lock to be acquired will be blocked if there is existing write lock, but will not be blocked if there are mutiple read locks already granted to other owners. On the other hand, a write lock can be acquired as long as there is no existing write lock, regardless how many read locks have been ...
• InvalidationsTxGrouper: Utility class that can be used to group invalidations in a set of BatchInvalidations structure and only commit them alltogether at transaction commit-time. The invalidations are grouped (in this order): - by transaction - by InvalidationManager instance - by InvalidationGroup This object will manage the transaction registering by itself if not already done. Thus, once a transaction commits, it will prepare a set of BatchInvalidation collections (one for each InvalidationManager involved): on BI instance for each InvalidationGroup. Then it will call the IM.batchInvalidation method.
• JGCacheInvalidationBridgeMBean: Cache Invalidation bridge working over JavaGroup. The partition to be used and the invalidation manager can be defined as part of the MBean interface. The bridge automatically discovers which are the InvalidationGroup that are managed by other node of the cluster and only send invalidation information for these groups over the network. This makes this bridge very easy to setup while still being efficient with network resource and CPU serialization cost.
• InvalidationGroup: An InvalidationGroup (IG) is the meeting point of all caches and invaliders working for the same cached information. For example, two entity beans based on the same database information will share their cache invalidation so that a modification performed on the bean of one of the deployed EJB will imply a cache invalidation in the cache of the other EJB. In this case, we say that both EJBs work in the same InvalidationGroup.
• InvalidationBridgeListener: InvalidationManager (IM) represents locally managed caches and invaliders. To be able to do distributed invalidations, it is necessary to bridge these IM to forward cache invalidation messages. The InvalidationBridgeListener provides the way for any transport mechanism to be used to forward cache invalidation messages accross a network/cluster.
• JMSCacheInvalidationBridgeMBean: Cache invalidation bridge based on JMS. The list of InvalidationGroup to be bridged is *not* automatically discovered, thus, all invalidation messages that are locally generated are forwarded over JMS. In the future, it should be possible, through a JMX attribute, to list the InvalidationGroup that should be included/excluded
• EntityBeanCacheBatchInvalidatorInterceptor: The role of this interceptor is to detect that an entity has been modified after an invocation has been performed an use the InvalidationsTxGrouper static class so that invalidation messages can be groupped and sent at transaction-commit time in a single batch.
• DeadlockTest: Tests transactional access to a local TreeCache, with concurrent (deadlock-prone) access. Note: we use DummpyTranasctionManager to replace jta
• ConcurrentBankTest: Unit test for local TreeCache with concurrent transactions. Uses locking and multiple threads to test concurrent r/w access to the tree.
• BridgeInvalidationSubscription: Every bridge subscribing to a InvalidationManager has access to this interface that it can used to invalidate messages on the local IM.
• SyncReplTxTest: Replicated unit test for sync transactional TreeCache Note: we use DummyTransactionManager for Tx purpose instead of relying on jta.
• BatchInvalidation: Structure that contains keys to be invalidated and the name of the group on which these invalidation must be performed.
• Link: Test class for TreeCacheAOP for circular references. Link is a POJO that will be instrumentet with CacheInterceptor
• AsyncReplTest: Unit test for replicated async TreeCache. Use locking and multiple threads to test concurrent access to the tree.
• TreeCacheAopTester: Proxy to the TreeCacheAop. The AOP framework requires that classes are loaded by special classloaders (e.g UCL).
• LocalConcurrentTest: Local mode stress test for TreeCacheAop. Test getObject, putObject and removeObject under load and concurrency.
• JMSCacheInvalidationBridge: JMS implementation of a cache invalidation bridge Based on previous code of Bill Burke based on interceptors
• ConcurrentTransactionalTest: Unit test for local TreeCache. Use locking and multiple threads to test concurrent access to the tree.
• TransactionTest: Tests transactional access to a local TreeCache. Note: we use DummpyTranasctionManager to replace jta
• ReplicatedTxAopTest: LocalTestCase.java that uses standalone aop package. Created: Mon May 05 17:30:11 2003
• ReplicatedAopTest: LocalTestCase.java that uses standalone aop package. Created: Mon May 05 17:30:11 2003
• LocalEvictionAopTest: LocalTestCase.java that uses standalone aop package. Created: Mon May 05 17:30:11 2003

Home | Contact Us | Privacy Policy | Terms of Service