The method takes already locked lock object as an argument.
The caller must ensure that the lock object owns the underlying mutex.
Replaced homegrown wsrep::unique_lock with type alias from
std::unique_lock.
This patch adds the possibility to have client commands that do not
return results from DBMS. While processing such commands we must be
able to preserve errors until the next interaction with client.
Specifically if the transaction is bf aborted while processing such
a non-returning command, then we have to keep the deadlock error until
the client issues a command that may return the error.
To handle such cases, client_state::before_command() now takes
parameter keep_command_error. The DBMS is supposed set
keep_command_error true to instruct wsrep-lib to preserve errors (if
any) until the next command which sets keep_command_error false.
Dealing with a case where current client command does not return result.
Work in progress.
Fix typo and add assertions in keep_command_error()
Make keep_command_error a parameter to before_commit()
Fix comment about keep_command_error
Handle keep_command_error with s_must_abort in wsrep_before_command()
Fix unit test
* Added unit tests for transaction::xa_detach() and
transaction::xa_replay()
* Added unit tests for wsrep::xid
* Fixed minor issues pointed out by reviewer
Assertion is_streaming() would trigger in transaction::before_commit()
if a one phase XA transaction was BF aborted at the right
time (because one phase XA transaction is not streaming yet at commit
time).
This patch implments replaying for prepared XA transactions.
Replay may happen in the following cases:
1) The transaction is BF aborted in prepared state and is idle. In
that case, the transaction is handed over to rollbacker for replay.
2) The transaction is BF aborted while executing the
commit (i.e. before or after successful certification). In
which case the transaction replays itself from fragment storage.
3) The transaction is BF aborted while certifying its commit
fragment. This case is handled like replay for streaming transactions,
where the provider is directly involved and re-delivers the last
fragment.
Add support for detaching XA transactions. This is useful for handling
the case where the DBMS client has a transaction in prepared state and
disconnects. Before disconnect, the DBMS calls the newly introduced
client_state::xa_detach(), to cleanup the local transaction and
convert it to a high priority transaction. The DBMS may later attempt
to terminate the transaction through client_state::commit_by_xid() or
client_state::rollback_by_xid().
Also in this patch:
- Fix client_state::close() so that it does not rollback transactions
in prepared state
- Changed class wsrep::xid representation to hold enough information
so that DBMS can convert to its native representation
- Fix potential infinite loop in
server_state::find_streaming_applier(wsrep:xid&)
- Append SR keys on prepare fragment and make it pa_unsafe
- Handle one phase commit (simply fall back to two phase)
- Do not rollback prepared streaming clients in
server_state::close_orphaned_transactions()
This patch changes the handling of a rollback fragment so that
the high_priority_service adopts and starts a new transaction only
if fragment removal has to be performed.
When no fragment removal happens, starting a new transaction is
unnecessary: a dummy write set is logged instead and the transaction
is not cleaned up properly in DBMS side.
Modified tests to verify that client_service::will_replay() is
called whenever it is determined that the transaction must replay.
Added a test to verify behavior when provider::commit_order_enter()
returns BF abort error.
Moved call to client_service::will_replay() into transaction::state()
to ensure that it is always called when shift to s_must_replay
happens.
Having aborted transaction holding a lock when releasing the
transaction in provider may cause a deadlock if:
- The transaction was BF aborted before it was known that the
latest fragment was successfully replicated,
- Transaction was going to be released on provider side, but
it waited for commit order,
- BF thread tried to grab lock for BF aborting, perhaps for
second time.
As a fix, unlock the lock protecting victim transaction for
the duration of transaction release.
All platforms do not have dl library, but dlopen() and friends
are included in libc.
Check existence of dl lib and store into WSREP_LIB_LIBDL if found.
An assertion
`server_state_.rollback_mode() == wsrep::server_state::rm_async`
fired in `client_state::before_command()` if a BF abort happened
between calls to wait_rollback_complete_and_acquire_ownership()
and before_command().
This commit adds a test to reproduce the assertion and verify
the correct behavior, as well as removes the incorrect assertion
to fix the issue.
which complicates diagnostics and debugging.
Don't ignore provider return codes and more verbose error logging for
sst_sent(), sst_received(), set_encryption_key() methods
Refs codership/wsrep-lib#127
After a local certification failure, commit order is released without
the setting the current position in DBMS. Which results in diverging
positions between provider and DBMS, if clean shutdown happens right
after local certification failure.
This patch add method set_position() to server_service class. So that
wsrep-lib can instruct DBMS to set the current position after local
certification failure releases commit order.
If the transaction fails during replay because of certification
failure, the provider will return control to applier without
terminating the transaction and transaction remains in
s_replaying.
Fixed transaction::after_statement() to handle the state changes
correctly if certification failure is returned from replay.
Replaying was extracted to separate private method from
after_statement(). Removed transaction::after_replay() as it
seems now unnecessary and it bypassed state change sanity checks.
Allowed replaying -> committed transaction transition to handle
the situation where DBMS allocates a new context and client_state
to do the replay.
Shutting down the provider may cause replication/appling failures, which
may further result to disconnect calls from failing operations.
Allow concurrent disconnect requests to deal with such a situations.
Adjusted transaction_xa_applying unit test to change in
applying_client_fixture. The fixture does not start transaction
and the transaction needs to be started in test explicitly.
when losing error voting:
- if NBO has failed locally (DBMS side), don't override original DBMS
error so it gets reported to the client
- otherwise, report "query interrupted" instead of "error during commit"
