Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: left join, jsonb_set

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

Code Block
languagejava
linenumberstrue
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;
}

...

  • The inability to simultaneously run multiple operations within a single connection

    Code Block
    languagejava
    linenumberstrue
    public void test1() {
      PostgresClient client = PostgresClient.getInstance(vertx, "diku");
      client.startTx(tx -> {
        for (int i = 0; i < 5; i++) {
    		// ConnectionStillRunningQueryException: [2] - There is a query still being run here - race -> false
          client.save(tx, UPLOAD_DEFINITION_TABLE, UUID.randomUUID().toString(), new UploadDefinition().withId(UUID.randomUUID().toString()), reply -> {
            if (reply.succeeded()) {
              System.out.println(reply.result());
            } else {
              System.out.println(reply.cause().getLocalizedMessage());
            }
          });
        }
      });
    }
    • This is not a problem of RMB but a limitation of PostgreSQL: "After successfully calling PQsendQuery, call PQgetResult one or more times to obtain the results. PQsendQuery cannot be called again (on the same connection) until PQgetResult has returned a null pointer, indicating that the command is done." (from 34.4. Asynchronous Command Processing). "One thread restriction is that no two threads attempt to manipulate the same PGconn object at the same time. In particular, you cannot issue concurrent commands from different threads through the same connection object. (If you need to run concurrent commands, use multiple connections.)" (from 34.19. Behavior in Threaded Programs).
  • A transaction is used within one connection and, accordingly, all subsequent actions must be performed in handlers and all errors must be manually processed. "Callback hell" as a result
  • There is no support for some kind of persistence context and all locks must be done manually in the database by separate requests
  • There is no possibility to easily manage the transaction isolation level at the application level
  • Since all objects are stored in JSON format in the database, there is no way to be sure that the data is stored correctly. At the moment there is an opportunity to save any JSON in any table
  • Because of the storage of objects in JSON format, it is not possible to build durable relationships between entities
  • It is necessary either to store all the links in one big JSON object in one table or put them into the other tables and create primary keys that do not guarantee contact with another entity. Need to make several requests to load data by primary keys and insert them into the parent object
  • RMB don't have all needed methods for working with transactions and queries.
  • RMB don't have method get() that using custom SQL script with transaction support

...