2.3.4 Estrategias de generación de claves primarias

Transcripción

1 2.3.4 Estrategias de generación de claves primarias

2 Estrategia 1 (1) Usar el mecanismo de generación de identificadores numéricos que proporciona la BD, en caso de que disponga de él; en otro caso, permitir integrar otra estrategia Ejemplo: Oracle y PostgreSQL proporcionan generadores de identificadores Es la estrategia que usa MiniBank

3 Estrategia 1 (2) <<Interface>> SQLAccountDAO AbstractSQLAccountDAO # AbstractSQLAccountDAO() + create(connection : Connection, accountvo : AccountVO) : AccountVO IGSQLAccountDAO + IGSQLAccountDAO() <<use>> <<Interface>> EntityIdentifierGenerator (from sql) + getnextidentifier(connection : Connection, entityname : String) : Long <<use>> EntityIdentifierGeneratorFactory (from sql) <<static>> - generatorclass : Class AbstractEntityIdentifierGenerator (from sql) - EntityIdentifierGeneratorFactory() <<static>> + getgenerator() : EntityIdentifierGenerator # AbstractEntityIdentifierGenerator() + getnextidentifier(connection : Connection, entityname : String) : Long # getquerystring(sequencename : String) : String PostgreSQLEntityIdentifierGenerator (from postgresql)

4 Estrategia 1 (y 3) Ventajas El generador de identificadores es reusable Es sencilla de implementar Suficientemente eficiente Desventajas Para insertar una nueva fila necesitamos realizar dos accesos a la BD: (1) generar el identificador y (2) insertar la fila Si la BD no proporciona generador de identificadores, es preciso implementar el método create Si proporciona columnas-contador, se debe insertar la fila sin especificar la clave (identificador) y luego leer el identificador generado En otro caso (ej.: Cloudscape), se puede usar la estrategia 3, o incluso la 2 en aplicaciones con poca carga

5 Estrategia 2 (1) Implementar EntityIdentifierGenerator en términos de la siguiente tabla entityname Account AccountOperation... nextidentifier getnextidentifier lee el valor nextidentifier de la fila correspondiente (es el valor que devuelve), le suma uno y lo almacena otra vez en la BD

6 Estrategia 2 (y 2) Problemas Número de accesos a la BD para insertar una nueva fila: 3 (2 por la generación del identificador y otro por la inserción) Si se usa SELECT FOR UPDATE para leer las filas o TRANSACTION_SERIALIZABLE con BDs con Pessimistic Locking => demasiados bloqueos Si se usa TRANSACTION_SERIALIZABLE con BDs con Optimistic Locking => con carga alta, se producirán muchas SQLExceptions Conclusión getnextidentifier podría hacer n reintentos, pero ocurrirá muchas veces y será lento Excepto para aplicaciones con poca carga, no es una estrategia válida

7 Estrategia 3: Sequence Blocks (1) Mejorar la estrategia 2 manteniendo un rango de identificadores en memoria La columna nextidentifier pasaría a llamarse lowerentityidentifier, que representaría el límite inferior de un rango de identificadores La implementación de EntityIdentifierGenerator mantendría un mapa que asocia <entiyname, <lowerentityidentifier, nextidentifier>> Inicialmente el mapa está vacío Si ((entityname está en el mapa) && (nextidentifier < lowerentityidentifier+k)) => Devolver nextidentifier e incrementarlo en una unidad En otro caso => lowerentityidentifier = Leer el valor de la columna lowerentityidentifier en la fila correspondiente (XXX) nextidentifier = lowerentityidentifier Actualizar la fila con el valor lowerentityidentifier+k Devolver nextidentifier e incrementarlo en una unidad

8 Estrategia 3: Sequence Blocks (2) El método getnextidentifier necesita ser sincronizado IdentifierGenerator debería ser un Singleton El concepto de Singleton es difuso en J2EE La máquina virtual Java garantiza que sólo hay una instancia de un Singleton por cada cargador de clases Una aplicación Java puede usar más de un cargador de clases (ej.: un contenedor de EJBs suele usar más de uno) Un contenedor de Servelts/JSP (que en teoría sólo dispone de un cargador de clases) o de EJBs podría estar replicado (cluster)=> existen otras tantas instancias de generadores de identificadores El concepto de singleton se puede implementar mediante un objeto distribuido (ej.: RMI o CORBA), pero no sería una solución eficiente El algoritmo anterior funciona aún habiendo más de una instancia del generador de identificadores Observar la línea XXX (se relee el valor de lowerentityidentifier cada vez que hay que incrementarlo en k unidades)

9 Estrategia 3: Sequence Blocks (3) Como consecuencia de lo anterior, y dado que la línea XXX y las 3 siguientes constituyen una transacción que lee un valor, lo actualiza en memoria y luego en BD Puede usarse SELECT FOR UDPATE en XXX, o Usar TRANSACTION_SERIALIZABLE para toda la transacción, haciendo n reintentos si la actualización de la fila provoca una SQLException De esta forma funciona tanto en BDs con Pessimistic Locking (que bloquean filas) como con BDs con Optimistic Locking (que generan una SQLException en caso de problemas de concurrencia) Es mejor que getnextidentifier no reciba la conexión, y en su lugar la pida En otro caso, la línea XXX y subsiguientes formarían parte de la misma transacción que la inserción de la nueva fila => la transacción es más larga y la BD mantiene filas bloquedas más tiempo

10 Estrategia 3: Sequence Blocks (y 4) Ventajas El generador de identificadores es reusable Número de accesos a la BD para insertar una nueva fila La mayor parte de las veces sólo 1 (inserción de la nueva fila) Cuando hay que leer un nuevo bloque de identificadores, 3 accesos (2 para leer y actualizar la columna lowerentityidentifier, y 1 para para insertar la nueva fila) Desventajas No se garantiza un orden de generación de identificadores La implementación es más compleja

11 Estrategia 4: UUID (1) UUID = Universally Unique IDentifier Generar la siguiente cadena de caracteres (1) (2) (3) (4) XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (1) System.currentTimeMillis() (2) Dirección IP (3) System.identityHashCode(this) (4) Número aleatorio obtenido con java.security.securerandom NOTAS Cada campo es de 8 caracteres y está codificado en hexadecimal (2) y (3) sólo necesitan calcularse una vez

12 Estrategia 4: UUID (y 2) Ventajas La clase que implemente esta estrategia no necesita tomar ninguna precaución aunque se use en un entorno en cluster La generación de identificadores se hace en memoria Desventajas Las claves generadas son identificadores de caracteres (de 32 caracteres) => los índices que se construyan sobre estas claves no serán tan eficientes como si fuesen numéricos

13 Estrategia 4: Procedimientos almacenados (1) En esta estrategia, se implementa el método create del DAO invocando un procedimiento almacenado para insertar la fila... CallableStatement call = con.preparecall( CALL insertaccount (?,?,?) ); call.setlong(1, accoutvo.getuseridentifier().longvalue()); call.setdouble(2, accountvo.getbalance()); call.registeroutparameter(3, java.sql.types.bigint); call.execute(); accountidentifier = new Long(call.getLong(3)); return new AccountVO(accountIdentifier, accountvo.getuseridentifier(), accountvo.getbalance());

14 Estrategia 4: Procedimientos almacenados (y 2) Esta estrategia funciona tanto con BDs que proporcionan generadores de identificadores como columnas-contador Si la BD no proporciona ninguno de estos mecanismos, se puede usar un tabla como la de la estrategia 2 (ahora no sería ineficiente, dado que la lectura y actualización de la fila se hace dentro del procedimiento almacenado) Ventajas Fácil de implementar Sólo se hace un acceso a la BD Desventajas Se necesita escribir un procedimiento almacenado para cada BD, dado que la sintaxis de los procedimientos almacenados no es portable Típicamente estará dentro del script de creación de tablas

15 JDBC 3.0 permitirá Estrategia 5 (1) Devolver el identificador de una fila recién insertada Se asume que la BD puede asociar un generador de identificadores a una columna (normalmente lo permiten casi todas) Permitirá implementar el método create en el DAO de manera portable y sin usar procedimientos almacenados Ejemplo... PreparedStatement preparedstatement = con.preparedstatement( "INSERT INTO Account (usrid, balance) VALUES (?,?)", Statement.RETURN_GENERATED_KEYS); preparedstatement.setlong(1, accoutvo.getuseridentifier().longvalue()); preparedstatement.setdouble(2, accountvo.getbalance()); preparedstatement.executeupdate();

16 Estrategia 5 (y 2) Ejemplo (cont) Long accountidentifier; ResultSet resultset = preparedstatement.getgeneratedkeys(); if (resultset.next()) { accountidentifier = new Long(resultSet.getLong(1)); } else { throw... } return new AccountVO(accountIdentifier, accountvo.getuseridentifier(), accountvo.getbalance()); Ventajas Tan eficiente como la estrategia de procedimientos almacenados (1 sólo acceso) Totalmente portable Será la solución definitiva!