stormpot 3.1 · stormpot.Slot

A Slot represents a location in a Pool where objects can be allocated into, so that they can be claimed and released. The Slot is used by the allocated Poolables as a call-back, to tell the pool when an object is released. The individual pool implementations provide their own Slot implementations. Slots contain mutable state within them. If objects are claimed, released and otherwise worked on from different threads, then the hand-over must happen through a safe publication mechanism. See Java Concurrency in Practice by Brian Goetz for more information on safe publication. Slots also expects single-threaded access, so they cannot be used concurrently by multiple threads. Only one thread at a time can use a Slot instance.

Modifier and Type	Method and Description
public void	expire(Poolable A reference to the Poolable object that is allocated for this slot, and is being expired. obj) Mark the object represented by this slot as expired.
public void	release(Poolable A reference to the Poolable object that is allocated for this slot, and is being released. obj) Signal to the pool that the currently claimed object in this slot has been released.

Method Detail

expire back to summary

expire	back to summary
public void expire(Poolable obj) Mark the object represented by this slot as expired. Expired objects cannot be claimed again, and will be deallocated by the pool at the earliest convenience. Objects are normally expired automatically using the `Expiration` policy that the pool has been configured with. If an object through its use is found to be unusable, then it can be explicitly expired using this method. Objects can only be explicitly expired while they are claimed, and such expired objects will not be deallocated until they are released back to the pool. It is a user error to expire objects that are not currently claimed. It is likewise a user error to expire a Slot while inside the Allocators `allocate` method. The expiration only takes effect after the object has been released, so calling this method from within the Expirations `hasExpired` method will not prevent the object from being claimed, but will prevent it from being claimed again after it's been released back to the pool. An Expiration policy that expires all objects with this method, is effectively allowing objects to only be claimed once. Pools are free to throw a PoolException if they detect any wrong uses, but it is not guaranteed and the exact behaviour is not specified. "Unspecified behaviour" means that dead-locks and infinite loops are fair responses as well. Therefore, heed the advice and don't misuse expire! Pools must, however, guarantee that an object is never `deallocated` more than once. This guarantee must hold even if expire is misused. Parameters obj:Poolable A reference to the Poolable object that is allocated for this slot, and is being expired.

public void expire(Poolable obj)

Mark the object represented by this slot as expired. Expired objects cannot be claimed again, and will be deallocated by the pool at the earliest convenience. Objects are normally expired automatically using the Expiration policy that the pool has been configured with. If an object through its use is found to be unusable, then it can be explicitly expired using this method. Objects can only be explicitly expired while they are claimed, and such expired objects will not be deallocated until they are released back to the pool. It is a user error to expire objects that are not currently claimed. It is likewise a user error to expire a Slot while inside the Allocators allocate method. The expiration only takes effect after the object has been released, so calling this method from within the Expirations hasExpired method will not prevent the object from being claimed, but will prevent it from being claimed again after it's been released back to the pool. An Expiration policy that expires all objects with this method, is effectively allowing objects to only be claimed once. Pools are free to throw a PoolException if they detect any wrong uses, but it is not guaranteed and the exact behaviour is not specified. "Unspecified behaviour" means that dead-locks and infinite loops are fair responses as well. Therefore, heed the advice and don't misuse expire! Pools must, however, guarantee that an object is never deallocated more than once. This guarantee must hold even if expire is misused.

Parameters

obj:Poolable: A reference to the Poolable object that is allocated for this slot, and is being expired.

release back to summary

release	back to summary
public void release(Poolable obj) Signal to the pool that the currently claimed object in this slot has been released. It is a user error to release a slot that is not currently claimed. It is likewise a user error to release a Slot while inside the Allocators `allocate` method, or the Expirations `hasExpired` method. On the other hand, it is _not_ an error to release a Poolable from a thread other than the one that claimed it. Pools are free to throw a PoolException if they detect any of these wrong uses, but it is not guaranteed and the exact behaviour is not specified. "Unspecified behaviour" means that dead-locks and infinite loops are fair responses as well. Therefore, heed the advice and don't misuse release! Pools must, however, guarantee that an object is never `deallocated` more than once. This guarantee must hold even if release is misused. Parameters obj:Poolable A reference to the Poolable object that is allocated for this slot, and is being released.

public void release(Poolable obj)

Signal to the pool that the currently claimed object in this slot has been released. It is a user error to release a slot that is not currently claimed. It is likewise a user error to release a Slot while inside the Allocators allocate method, or the Expirations hasExpired method. On the other hand, it is _not_ an error to release a Poolable from a thread other than the one that claimed it. Pools are free to throw a PoolException if they detect any of these wrong uses, but it is not guaranteed and the exact behaviour is not specified. "Unspecified behaviour" means that dead-locks and infinite loops are fair responses as well. Therefore, heed the advice and don't misuse release! Pools must, however, guarantee that an object is never deallocated more than once. This guarantee must hold even if release is misused.

Parameters

obj:Poolable: A reference to the Poolable object that is allocated for this slot, and is being released.

public Interface Slot

Method Summary

Method Detail