[master < T577] Transactional queue

[as51340]

[master < Epic] PR

• Check, and update documentation if necessary
• Write E2E tests
• Compare the benchmarking results between the master branch and the Epic branch
• Provide the full content or a guide for the final git message

To keep docs changelog up to date, one more thing to do:

• Write a release note here
• Tag someone from docs team in the comments

[as51340]

Few comments so it is clear what is happening, for me and for reviewers. To expose transactions, we have to somehow save all interpreters. The first idea was to save BoltSessions so in the future we could add killing by session id. However, we decided not to use this approach because of complications that are occurring in the implementation (mostly circular dependencies issue).

Interpreters are saved as a raw pointer in a vector synced with a SpinLock. This should suffice in securing that multiple threads cannot modify interpreter object. Storing a raw pointer is not great but I think there shouldn't be a problem if we are deregistering it from the vector of interpreters in the destructor of the BoltSession since interpreter is completely managed within the BoltSession. Streams are covered so that at the beginning of the CreateConsumer method, interpreter is registered and at exit, deregistered. Interpreter may be active without a running transaction so to cover this case, is_transaction_active from storage accessor is used.

Authorization is implemented by using two approaches:

1. user can kill its own transactions
2. user that has all privileges (admin) can kill any transaction
   This required extending the interpreter so that it saves the username of the user running queries on the interpreter.

• transaction_id is returned as string because of the overflow

• this PR is the only that needs to be reviewed because I merged Ante's into this one since he is sick.

• tests will be added in the meantime

[antoniofilipovic]

Please merge the main into epic E578-MG and merge epic E578-MG into this branch T577-FL, because there is code from PR of ReferenceBasedEvaluator here.

[Josipmrden]

Changes needed, but overall very good, not too many changes on the architecture!

[antoniofilipovic]

One small change from me, and that should be it

[antoniofilipovic]

Looks good to me, I would just change the naming of transaction statuses.

Also, I think we can discuss on Monday, whether it makes sense to push transaction status info down to storage::Accessor as there is also information about the status of transactions for each. It would make sense to me, as we could make then call

interpreter->GetTransactionStatus()

And in interpreter we would have following check:

std::optional<uint64_t> Storage::Accessor::GetTransactionId() const {
  if (is_transaction_active_) {
    return transaction_.transaction_id.load(std::memory_order_acquire);
  }
  return {};
}

And Storage::Accessor would have 1:1 mapping with Transaction and we could easily be sure that interpreter is not in charge of TransactionStatus, but that is to Storage::Accessor

I am not sure if it makes sense but does to me.

Otherwise, I am confident enough that nothing should break, as with introduction of CheckingStatus, we should prevent deadlocks of any sort, or any damage.