Home >> All >> org >> jboss >> ejb >> plugins >> [ lock Javadoc ]

• org.jboss.ejb.plugins.lock: Javadoc index of package org.jboss.ejb.plugins.lock.


Package Samples:

• org.jboss.ejb.plugins.lock: Package description goes here .  

Classes:

• JDBCOptimisticLock: This class is an optmistic lock implementation. It locks tableFields and their values during transaction. Locked tableFields and their values are added to the WHERE clause of the UPDATE SQL statement when entity is stored. The following strategies are supported: - fixed group of tableFields Fixed group of tableFields is used for locking . The tableFields and their values are locked at the beginning of a transaction. The group name must match one of the entity's load-group-name. - modified strategy The tableFields that were modified during transaction are used as lock. All entity's field values ...
• QueuedPessimisticEJBLock: This class is holds threads awaiting the transactional lock to be free in a fair FIFO transactional queue. Non-transactional threads are also put in this wait queue as well. Unlike SimplePessimisticEJBLock which notifies all threads on transaction completion, this class pops the next waiting transaction from the queue and notifies only those threads waiting associated with that transaction. This class should perform better than Simple on high contention loads. Holds all locks for entity beans, not used for stateful. All BeanLocks have a reference count. When the reference count goes to 0, the lock ...
• SimpleReadWriteEJBLock: This lock allows multiple read locks concurrently. Once a writer has requested the lock, future read-lock requests whose transactions do not already have the read lock will block until all writers are done -- then all the waiting readers will concurrently go (depending on the reentrant setting / methodLock). A reader who promotes gets first crack at the write lock -- ahead of other waiting writers. If there is already a reader that is promoting, we throw an inconsistent read exception. Of course, writers have to wait for all read-locks to release before taking the write lock.
• ApplicationDeadlockException: This exception class is thrown when application deadlock is detected when trying to lock an entity bean This is probably NOT a result of a jboss bug, but rather that the application is access the same entity beans within 2 different transaction in a different order. Remember, with a PessimisticEJBLock, Entity beans are locked until the transaction commits or is rolled back.
• MethodOnlyEJBLock: This class has been deprecated. Holds all locks for entity beans, not used for stateful. All BeanLocks have a reference count. When the reference count goes to 0, the lock is released from the id -> lock mapping.
• NoLock: No locking what-so-ever Holds all locks for entity beans, not used for stateful. All BeanLocks have a reference count. When the reference count goes to 0, the lock is released from the id -> lock mapping.
• NonReentrantLock: Implementents a non reentrant lock with deadlock detection It will throw a ReentranceException if the same thread tries to acquire twice or the same transaction tries to acquire twice
• QueuedPessimisticEJBLockNoADE: A subclass of QueuedPessimisticEJBLock that disables the deadlock detection of QueuedPessimisticEJBLock.
• Entrancy: This type safe enumeration s used to mark an invocation as non-entrant.
• BeanLockSupport: Support for the BeanLock

Home | Contact Us | Privacy Policy | Terms of Service