Page Comparison

Current approach to working with transactions in RMB

To enable the work with a database in FOLIO project there is a custom solution implemented on top of the VERT.X Postgres Client. The main feature of working with RMB and VERT.X is the usage of the asynchronous approach. Sequential execution of operations requires handling the completion of each operation and occurring errors. Each subsequent operation can be executed only if the previous one is succeeded. In order to maintain data consistency there is a need to execute the operations in transaction and be able to rollback the changes in case an error occurred. At the moment, this possibility is implemented as follows:

...

The First and the last operations RMB PostgresClient does automatically

Example method with two operation in scope of one transaction

public Future<Void> example() {
  Future future = Future.future();
  PostgresClient client = PostgresClient.getInstance(vertx, tenantId);
  // start tx
  client.startTx(tx -> {
    // first operation
    client.get(tx, "upload_definition", UploadDefinition.class, new Criterion(), true, false, getHandler -> {
      if (getHandler.succeeded()) {
        // second operation
        client.save(tx, "upload_definition", UUID.randomUUID().toString(), getHandler.result(), saveHandler -> {
          if (saveHandler.succeeded()) {
            client.endTx(tx, endHandler -> {
              if (endHandler.succeeded()) {
                future.succeeded();
              } else {
                client.rollbackTx(tx, rollbackHandler -> {
                  future.fail(getHandler.cause());
                });
              }
            });
          } else {
            client.rollbackTx(tx, rollbackHandler -> {
              future.fail(getHandler.cause());
            });
          }
        });
      } else {
        client.rollbackTx(tx, rollbackHandler -> {
          future.fail(getHandler.cause());
        });
      }
    });
  });
  return future;
}

...

• Refactoring of the RMB's PostgresClient and add a couple of new methods for updating with blocking, transactions and loading records with the blocking of the record itself in the scope of the transaction

  • Create a single approach to query data from the database. For now get, save, update, delete methods at PostgresClient have different query mechanisms: CQLWrapper, Criterion, UUID. Need to create a wrapper for the querying functionality or encapsulate this logic.

  • Add a possibility to run custom SQL with “SELECT” statements.

    • Use one of the PostgresClient.select methods.

  • Add methods for an update with row blocking in the table.

    • There are several non-transactional update methods and two transactional update methods. Please file an issue against RMB for each missing transactional update method that you need.

  • Add batchUpdate method

    • There are 9 update methods. Please file an issue against RMB for each single method that you need with batch capability.

    • Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key RMB-374

  • Change saveBatch method. For now, it doesn’t work with ids in the table.

    • Is this 

      Jira Legacy
      server System Jira serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key RMB-204

      what you need? If not please file an issue against RMB for each single method that you need.
  • Create a transaction helper for PostgresClient similar to rxjava 2 SQLClientHelper (PostgresClient doesn't support rxjava2, but creating a similar helper is straightforward).
• Investigate the possibility of using other database tools. Conduct a study on the compatibility of the vert.x framework and existing solutions for the database, perhaps even synchronous solutions.

...