I have been working on extensions to add support for Cassandra. While Cassandra is not a RDBMS the work around CQL (cassandra query language) has produced tools like cassandra-jdbc, a JDBC driver for Cassandra. The DML, e.g., select, update, etc. functionality is rather limited though. Much of this is due to the fact that Cassandra is not relational database. One place where I ran into trouble is with LockDatabaseChangeLogGenerator. I cannot run that update statement against Cassandra.
My preference, at least at this stage, would be to somehow disable or turn off the locking. I have tried simulating that with a few extensions, notablly LockDatabaseChangeLogGeneratorCassandra and UnlockDatabaseChangeLogGeneratorCassandra. LockDatabaseChangeLogGeneratorCassandra applies a simple update that always sets the locked column to true, and UnlockDatabaseChangeLogGeneratorCassandra also sets the column to false. I ran into problems though in the LockService.acquireLock method at line 104ish which is,
int rowsUpdated = executor.update(new LockDatabaseChangeLogStatement());
My problem is that rowsUpdated is always 0 even though the update happens. The reason being is that the update operation translates to an operation on the server with a return type of void; consequently, the cassandra jdbc driver always returns 0 when its implementation of java.sql.Statement.executeUpdate is invoked. LockService is never able to get the lock. The return value of zero makes sense because there really isn’t a good way to indicate the number of rows updated. The update might not happen immediately as it has to propagate across nodes in the cluster. Furthermore, one of the target nodes that should receive the update could be down, and when it comes back up, it will receive and apply that update.
At this point, I do not see how to work around this using the existing extension points. I want to know how feasible it would be to add an extension point either for LockService or for Executor. Extending LockService would allow me to more or less turn off locking, but maybe extending Executor would be a safer, more narrowly scoped change. I basically want to wrap JDBCExecutor and intercept the call to update(new LockDatabaseChangeLogStatement()).
I am currently blocked on this. If this is doable, I am more than happy to work on and provide a patch.