Liquibase lock - razones?

Obtengo esto cuando ejecuto muchos scripts de liquibase contra un servidor Oracle. SomeComputer soy yo.

Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Waiting for changelog lock....
Liquibase Update Failed: Could not acquire change log lock.  Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
SEVERE 2013-03-20 16:59:liquibase: Could not acquire change log lock.  Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
liquibase.exception.LockException: Could not acquire change log lock.  Currently locked by SomeComputer (192.168.15.X) since 2013-03-20 13:39
        at liquibase.lockservice.LockService.waitForLock(LockService.java:81)
        at liquibase.Liquibase.tag(Liquibase.java:507)
        at liquibase.integration.commandline.Main.doMigration(Main.java:643)
        at liquibase.integration.commandline.Main.main(Main.java:116)

¿Podría ser que se alcance el número de sesiones / transacciones simultáneas? Alguien tiene alguna idea?

A veces, si la aplicación de actualización se detiene abruptamente, el bloqueo permanece atascado.

Entonces corriendo

UPDATE DATABASECHANGELOGLOCK SET LOCKED=0, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

contra la base de datos ayuda.

O simplemente puede dejar caer la DATABASECHANGELOGLOCKtabla, se volverá a crear.

Editar junio 2020

No sigas este consejo. Ha causado problemas a muchas personas a lo largo de los años. Funcionó para mí hace mucho tiempo y lo publiqué de buena fe, pero claramente no es la forma de hacerlo. La tabla DATABASECHANGELOCK debe contener elementos, por lo que es una mala idea simplemente eliminar todo de ella.

Leos Literak , por ejemplo, siguió estas instrucciones y el servidor no pudo iniciarse.

Respuesta original

Posiblemente se deba a un proceso de liquibase muerto que no libera su bloqueo en la tabla DATABASECHANGELOGLOCK. Luego,

DELETE FROM DATABASECHANGELOGLOCK;

podría ayudarte

Editar: la respuesta de @Adrian Ber proporciona una solución mejor que esta. Solo haga esto si tiene algún problema para hacer su solución.

El problema fue la implementación defectuosa de SequenceExists en Liquibase. Dado que los conjuntos de cambios con estas declaraciones tomaron mucho tiempo y fueron abortados accidentalmente. Luego, en el siguiente intento de ejecutar las secuencias de comandos liquibase, se mantuvo el bloqueo.

  <changeSet author="user" id="123">
    <preConditions onFail="CONTINUE">
      <not><sequenceExists sequenceName="SEQUENCE_NAME_SEQ" /></not>
    </preConditions>
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/>
  </changeSet>

Una solución alternativa es usar SQL simple para verificar esto en su lugar:

  <changeSet author="user" id="123">
    <preConditions onFail="CONTINUE">
            <sqlCheck expectedResult="0">
              select count(*) from user_sequences where sequence_name = 'SEQUENCE_NAME_SEQ';
            </sqlCheck>
    </preConditions>
    <createSequence sequenceName="SEQUENCE_NAME_SEQ"/>
  </changeSet>

Lockdata se almacena en la tabla DATABASECHANGELOCK. Para deshacerse del bloqueo, simplemente cambie 1 a 0 o suelte esa tabla y vuelva a crearla.

No se menciona qué entorno se utiliza para ejecutar Liquibase. En caso de que sea Spring Boot 2, es posible extenderlo liquibase.lockservice.StandardLockServicesin la necesidad de ejecutar sentencias SQL directas, lo cual es mucho más limpio. P.ej:

/**
 * This class is enforcing to release the lock from the database.
 *
 */
 public class ForceReleaseLockService extends StandardLockService {

    @Override
    public int getPriority() {
        return super.getPriority()+1;
    }

    @Override
    public void waitForLock() throws LockException {
        try {
            super.forceReleaseLock();
        } catch (DatabaseException e) {
            throw new LockException("Could not enforce getting the lock.", e);
        }
        super.waitForLock();
    }
}

El código impone la liberación del bloqueo. Esto puede ser útil en configuraciones de prueba en las que la llamada de liberación podría no llamarse en caso de errores o cuando se cancela la depuración.

La clase debe colocarse en el liquibase.extpaquete y será recogida por la configuración automática de Spring Boot 2.

A veces, truncar o soltar la tabla DATABASECHANGELOGLOCK no funciona. Utilizo la base de datos PostgreSQL y me encontré con este problema muchas veces. Lo que hago para resolver es revertir las declaraciones preparadas que se ejecutan en segundo plano para esa base de datos. Intente revertir todas las declaraciones preparadas e intente los cambios de liquibase nuevamente.

SQL:

SELECT gid FROM pg_prepared_xacts WHERE database='database_name';

Si la declaración anterior devuelve algún registro, revierta esa declaración preparada con la siguiente declaración SQL.

ROLLBACK PREPARED 'gid_obtained_from_above_SQL';

Puede eliminar de forma segura la tabla manualmente o mediante la consulta. Será recreado automáticamente.

DROP TABLE DATABASECHANGELOGLOCK;

Aprecio que este no era el problema del OP, pero recientemente me encontré con este problema con una causa diferente. Como referencia, estaba usando el complemento Liquibase Maven (liquibase-maven-plugin: 3.1.1) con SQL Server.

De todos modos, había copiado y pegado erróneamente una declaración de "uso" de SQL Server en uno de mis scripts que cambia las bases de datos, por lo que liquibase se estaba ejecutando y actualizando DATABASECHANGELOGLOCK, adquiriendo el bloqueo en la base de datos correcta, pero luego cambiando las bases de datos para aplicar los cambios. No solo no pude ver mis cambios o la auditoría de liquibase en la base de datos correcta, sino que, por supuesto, cuando volví a ejecutar liquibase, no pudo adquirir el bloqueo, ya que el bloqueo se había liberado en la base de datos "incorrecta", y así fue todavía bloqueado en la base de datos "correcta". Esperaba que liquibase verificara que el bloqueo todavía se aplicaba antes de liberarlo, y tal vez eso sea un error en liquibase (aún no lo he verificado), ¡pero es posible que se aborde en versiones posteriores! Dicho esto, supongo que podría considerarse una característica.

Es un error de colegial, lo sé, pero lo menciono aquí en caso de que alguien tenga el mismo problema.