Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sqlite locks when attempting a migration result in SQLException: [SQLITE_BUSY] #1499

Closed
taufiqkh opened this issue Dec 30, 2016 · 4 comments
Closed

Comments

@taufiqkh
Copy link

@taufiqkh taufiqkh commented Dec 30, 2016

What version of Flyway are you using?

4.0.3

Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin, SBT plugin, ANT tasks)

Java API

What database are you using (type & version)?

SQLite Xerial JDBC driver 3.8.11.2

What operating system are you using?

Windows 10 64-bit

What did you do?

(Please include the content causing the issue, any relevant configuration settings, and the command you ran)
Attempted a migration that included table creation, using a flyway object with DataSource set to preconfigured org.sqlite.SQLiteDataSource. No other processes using the database as far as I am aware:

        SQLiteConfig config = new SQLiteConfig();
        config.setJournalMode(SQLiteConfig.JournalMode.WAL);
        config.setSynchronous(SQLiteConfig.SynchronousMode.NORMAL);
        SQLiteDataSource dataSource = new SQLiteDataSource(config);
        dataSource.setUrl("jdbc:sqlite:" + DB_NAME);
        Flyway flyway = new Flyway();
        flyway.setDataSource(dataSource);
        flyway.setLocations("filesystem:migrations");
        flyway.migrate();

Test migration script V2__test.sql:

CREATE TABLE FOO (
TEST INTEGER NOT NULL
);
What did you expect to see?

Successful migration to v2

What did you see instead?

The following exception:

Exception in thread "main" org.flywaydb.core.api.FlywayException: Unable to insert row for version '2' in metadata table "main"."schema_version"
	at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addAppliedMigration(MetaDataTableImpl.java:178)
	at org.flywaydb.core.internal.command.DbMigrate.applyMigration(DbMigrate.java:340)
	at org.flywaydb.core.internal.command.DbMigrate.access$1000(DbMigrate.java:47)
	at org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:230)
	at org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:173)
	at org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)
	at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:173)
	at org.flywaydb.core.Flyway$1.execute(Flyway.java:959)
	at org.flywaydb.core.Flyway$1.execute(Flyway.java:917)
	at org.flywaydb.core.Flyway.execute(Flyway.java:1373)
	at org.flywaydb.core.Flyway.migrate(Flyway.java:917)
	at com.quiptiq.flyway.ExampleFlyway.attemptMigration(ExampleFlyway.java:56)
	at com.quiptiq.flyway.ExampleFlyway.main(ExampleFlyway.java:44)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.sql.SQLException: [SQLITE_BUSY]  The database file is locked (database is locked)
	at org.sqlite.core.DB.newSQLException(DB.java:890)
	at org.sqlite.core.DB.newSQLException(DB.java:901)
	at org.sqlite.core.DB.execute(DB.java:807)
	at org.sqlite.core.DB.executeUpdate(DB.java:847)
	at org.sqlite.jdbc3.JDBC3PreparedStatement.executeUpdate(JDBC3PreparedStatement.java:86)
	at org.flywaydb.core.internal.dbsupport.JdbcTemplate.update(JdbcTemplate.java:275)
	at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.addAppliedMigration(MetaDataTableImpl.java:153)
	... 17 more
@taufiqkh
Copy link
Author

@taufiqkh taufiqkh commented Dec 30, 2016

Created repository containing an example.

@taufiqkh
Copy link
Author

@taufiqkh taufiqkh commented Dec 30, 2016

Possibly related to #1318 and #1180. As a workaround, I tried creating a wrapper DataSource that uses an underlying SQLiteDataSource but returns the same connection each time getConnection() is called unless that connection is closed. The migration appears to proceed as expected when this wrapper is provided, though I'm not familiar enough with Flyway to know if it will have any side effects. This is not thread safe but seems fine otherwise. Sample:

public class WorkaroundDataSource implements DataSource {
    private final SQLiteDataSource dataSource;

    private Connection connection;

    public WorkaroundDataSource(SQLiteDataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public Connection getConnection() throws SQLException {
        if (connection == null || connection.isClosed()) {
            this.connection = dataSource.getConnection();
        }
        return connection;
    }

    // other methods passed through to dataSource
    // ...
}
@axelfontaine axelfontaine added this to the Flyway 4.1 milestone Jan 25, 2017
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Jan 25, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jan 25, 2017

Thanks for the investigation. Truly appreciated!

We used to only force the use of a single connection when using our own datasource via flyway.setDataSource(url, user, pwd).

We have now fixed this to work with any datasource.

@taufiqkh
Copy link
Author

@taufiqkh taufiqkh commented Jan 27, 2017

No worries, workaround will do us for now but looking forward to the next update.

pradheeps pushed a commit to pradheeps/flyway that referenced this issue Mar 7, 2017
pradheeps pushed a commit to pradheeps/flyway that referenced this issue Mar 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.