Los desalojadores están asociados con instancias de BackingMap.
import com.ibm.websphere.objectgrid.ObjectGridManagerFactory;
import com.ibm.websphere.objectgrid.ObjectGridManager;
import com.ibm.websphere.objectgrid.ObjectGrid;
import com.ibm.websphere.objectgrid.BackingMap;
import com.ibm.websphere.objectgrid.TTLType;
ObjectGridManager ogManager = ObjectGridManagerFactory.getObjectGridManager();
ObjectGrid og = ogManager.createObjectGrid( "grid" );
BackingMap bm = og.defineMap( "myMap" );
bm.setTtlEvictorType( TTLType.CREATION_TIME );
bm.setTimeToLive( 600 );
El argumento del método setTimeToLive es 600 porque indica que el tiempo de vida está en segundos. El código anterior se debe ejecutar antes de que se invoque al método initialize en la instancia de ObjectGrid. Estos atributos BackingMap no se pueden modificar después de que se inicialice la instancia de ObjectGrid. Después de ejecutar el código, cualquier entrada que se inserte en la BakingMap myMap tiene una hora de caducidad. Una vez que se ha alcanzado la hora de caducidad, el desalojador TTL elimina la entrada.
Para definir como hora de caducidad la hora del último acceso más 10 minutos, cambie el argumento que se pasa al método setTtlEvictorType de TTLType.CREATION_TIME a TTLType.LAST_ACCESS_TIME. Con este valor, la hora de caducidad se calcula como la hora del último acceso más diez minutos. Cuando se crea una entrada por primera vez, la hora del último acceso es la hora de creación. Para basar la hora de caducidad en la última actualización, en lugar de solo en el último acceso (tanto si interviene o no una actualización), sustituya el valor TTLType.LAST_UPDATE_TIME por el valor TTLType.LAST_ACCESS_TIME.
Cuando se utiliza el valor TTLType.LAST_ACCESS_TIME, o TTLType.LAST_UPDATE_TIME se pueden utilizar las interfaces ObjectMap y JavaMap para sustituir el valor de tiempo de vida de BackingMap. Este mecanismo permite que una aplicación utilice un valor de tiempo de vida distinto para cada entrada que se cree. Supongamos que el fragmento de código anterior ha definido el atributo de ttlType como LAST_ACCESS_TIME y ha definido 10 minutos como valor de tiempo de vida. Una aplicación entonces puede alterar temporalmente el valor del tiempo de vida de todas las entradas ejecutando el siguiente código antes de crear o modificar una entrada:
import com.ibm.websphere.objectgrid.Session;
import com.ibm.websphere.objectgrid.ObjectMap;
Session session = og.getSession();
ObjectMap om = session.getMap( "myMap" );
int oldTimeToLive1 = om.setTimeToLive( 1800 );
om.insert("key1", "value1" );
int oldTimeToLive2 = om.setTimeToLive( 1200 );
om.insert("key2", "value2" );
En el fragmento de código anterior, la entrada con la clave key1 tiene una fecha de caducidad del tiempo de inserción más 30 minutos como resultado de la invocación del método setTimeToLive( 1800 ) en la instancia de ObjectMap. La variable oldTimeToLive1 se establece en 600 ya que el valor de tiempo de vida de BackingMap se utiliza como valor predeterminado si no se ha llamado previamente al método setTimeToLive en la instancia de ObjectMap.
La entrada con la clave key2 tiene una hora de caducidad del tiempo de inserción más 20 minutos como resultado de la invocación del método setTimeToLive( 1200 ) en la instancia de ObjectMap. La variable oldTimeToLive2 se establece en 1800 ya que el valor de tiempo de vida de la invocación anterior del método ObjectMap.setTimeToLive ha establecido el tiempo de vida en 1800.
El ejemplo anterior muestra la inserción de dos entradas de correlación en la correlación myMap para las claves key1 y key2. Más adelante, la aplicación puede seguir actualizando estas entradas de correlación y mantener a la vez los valores de tiempo de vida que se utilizan en el momento de la inserción para cada entrada de correlación. El siguiente ejemplo muestra cómo mantener los valores de tiempo de vida utilizando una constante definida en la interfaz ObjectMap:
Session session = og.getSession();
ObjectMap om = session.getMap( "myMap" );
om.setTimeToLive( ObjectMap.USE_DEFAULT );
session.begin();
om.update("key1", "updated value1" );
om.update("key2", "updated value2" );
om.insert("key3", "value3" );
session.commit();
Dado que el valor especial de ObjectMap.USE_DEFAULT se utiliza en la llamada al método setTimeToLive, la clave key1 mantiene su valor de tiempo de vida de 1800 segundos y la clave key2 retiene su valor de tiempo de vida de 1200 segundos porque estos valores se utilizaron cuando la transacción anterior insertó estas entradas de correlaciones.
El ejemplo anterior también muestra una nueva entrada de correlación para la inserción de la clave key3nsert. En este caso, el valor especial USE_DEFAULT indica que se debe utilizar el valor predeterminado del tiempo de vida para esta correlación. El valor predeterminado lo define el atributo BackingMap del tiempo de vida. Consulte Consulte los atributos de la interfaz BackingMap si desea más información sobre cómo se define el atributo tiempo de vida en la instancia de BackingMap.
Consulte la documentación de la API para el método setTimeToLive en las interfaces ObjectMap y JavaMap. La documentación explica que se genera una excepción IllegalStateException si el método BackingMap.getTtlEvictorType devuelve cualquier cosa distinta al valor TTLType.LAST_ACCESS_TIME o TTLType.LAST_UPDATE_TIME. Las interfaces ObjectMap y JavaMap pueden sustituir el valor de tiempo de vida sólo cuando se utiliza el valor LAST_ACCESS_TIME o TTLType.LAST_UPDATE_TIM para el tipo de desalojador TTL. El método setTimeToLive no se puede utilizar para sustituir el valor de tiempo de vida cuando se utiliza el valor de tipo de desalojador CREATION_TIME o NONE.
Dado que los desalojadores están asociados a BackingMaps, utilice la interfaz BackingMap para especificar el desalojador conectable. El siguiente fragmento de código es un ejemplo para especificar un desalojador LRUEvictor para la BackingMap map1 y un desalojador LFUEvictor para la instancia del BackingMap map2:
import com.ibm.websphere.objectgrid.ObjectGridManagerFactory;
import com.ibm.websphere.objectgrid.ObjectGridManager;
import com.ibm.websphere.objectgrid.ObjectGrid;
import com.ibm.websphere.objectgrid.BackingMap;
import com.ibm.websphere.objectgrid.plugins.builtins.LRUEvictor;
import com.ibm.websphere.objectgrid.plugins.builtins.LFUEvictor;
ObjectGridManager ogManager = ObjectGridManagerFactory.getObjectGridManager();
ObjectGrid og = ogManager.createObjectGrid( "grid" );
BackingMap bm = og.defineMap( "map1" );
LRUEvictor evictor = new LRUEvictor();
evictor.setMaxSize(1000);
evictor.setSleepTime( 15 );
evictor.setNumberOfLRUQueues( 53 );
bm.setEvictor(evictor);
bm = og.defineMap( "map2" );
LFUEvictor evictor2 = new LFUEvictor();
evictor2.setMaxSize(2000);
evictor2.setSleepTime( 15 );
evictor2.setNumberOfHeaps( 211 );
bm.setEvictor(evictor2);
El fragmento anterior muestra un desalojador LRUEvictor utilizado para la BackingMap map1 con un número máximo de entradas aproximado de 53.000 (53 * 1000). El desalojador LFUEvictor se utiliza para la BackingMap map2 con un número máximo aproximado de entradas de 422.000 (211 * 2000). Los desalojadores LRU y LFU tienen una propiedad de tiempo de inactividad que indica durante cuánto tiempo está inactivo el desalojador antes de entrar en actividad y comprobar si es necesario desalojar alguna entrada. El tiempo de inactividad se especifica en segundos. Un valor de 15 segundos constituye un buen término medio entre el impacto en el rendimiento y cómo evitar que BackingMap crezca demasiado. El objetivo es utilizar el mayor tiempo de inactividad posible sin provocar que BackingMap aumente excesivamente de tamaño.
El método setNumberOfLRUQueues establece la propiedad de LRUEvictor que indica cuántas colas LRU utiliza el desalojador para gestionar la información LRU. Una colección de colas se utiliza de modo que cada entrada no mantenga la información LRU en la misma cola. Este enfoque puede mejorar el rendimiento al minimizar el número de entradas de correlación que necesiten sincronizarse en el mismo objeto de cola. Un buen modo de minimizar el impacto que el desalojador LRU puede tener en el rendimiento consiste en aumentar el número de colas. Un buen punto de partida es utilizar el diez por ciento del número máximo de entradas como número de colas. Generalmente es mejor utilizar un número primo que uno que no lo sea. El método setMaxSize indica cuántas entradas se permiten en cada cola. Cuando una cola alcanza su número máximo de entradas, la entrada o las entradas menos utilizadas recientemente en esa cola se desalojarán la próxima vez que el desalojador compruebe si hay alguna entrada que es necesario desalojar.
El método setNumberOfHeaps establece la propiedad LFUEvictor para establecer cuántos objetos de almacenamiento dinámico binario utiliza LFUEvictor para gestionar información de LFU. En este caso también se utiliza una colección para mejorar el rendimiento. La utilización del diez por ciento del número máximo de entradas es un buen punto de partida, y un número primo es generalmente mejor que uno que no lo sea. El método setMaxSize indica cuántas entradas se permiten en cada almacenamiento dinámico. Cuando un almacenamiento dinámico alcanza su número máximo de entradas, la entrada o las entradas menos utilizadas frecuentemente en ese almacenamiento dinámico se desalojarán la próxima vez que el desalojador compruebe si hay alguna entrada que es necesario desalojar.