Skip to content

Use single DB connection per session for operate with all dataspaces

Pavel Kisliak requested to merge epam/one_db_conn_per_session into main

Type of change

  • Bug Fix
  • Feature

Does this introduce a change in the core logic?

  • [Yes]

Does this introduce a change in the cloud provider implementation, if so which cloud?

  • AWS
  • Azure
  • GCP
  • IBM

Updates description

The main purpose of this MR is to reduce number of opened DB connections that needed for every session (part of work for issue: #48 (closed)).
I've figured out that just one client can make server unavailable if he will make requests to 99 different dataspaces in the same session.

  • Use single DB connection per session for operate with all dataspaces
  • Deny writing to dataspaces which are not specified in StartTransaction (reading without restrictions)
  • Allow creation of dataspace in the transaction (previously, the dataspace specified in StartTransaction must already exist).
  • Remove several unused fields from OpenKVSession
  • Add more tests for confirm that logic works fine with single DB connection
  • Minor refactoring in the tests, moving useful ScopedSchema class to the header

There are no needs to use separate DB connections for work with different spaces, I've made several tests for confirm this:

  • test_execute_prepared_on_different_schemas
  • test_transaction_commit_on_different_schemas
  • test_transaction_rollback_on_different_schemas
  • test_Store4_PutDataObjects_in_multiple_spaces
  • test_Store4_GetDataObjects_from_multiple_spaces
  • test_Store4_DeleteDataObjects_from_multiple_spaces

So, prepared DB statements works fine on different schemas (as they are have same structure) and correctly works with transactions.

(!) Please pay attention to change "Deny writing to dataspaces which are not specified in StartTransaction".
Previously, writing to dataspace which is not specified in the StartTransaction was performed via different DB connection for exclude it from DB transaction. It's not described in the ETP specification and from my point of view, looks like as 'hidden' behavior which can lead to unexpected errors. I think that client doesn't expect that something can be excluded from transaction, he can just forget to include dataspace to StartTransaction. Please let me know if you have any concerns.

These changes also will allow to enable multi-space transactions, just need to enable pass more than one dataspace and fix/write tests.

Edited by Pavel Kisliak

Merge request reports