Storing information that background rollbacker in ongoing in client state has_rollback_
This can be used for detecting if there is ongoing background rollback,
and client should keep waiting in before_command() entry to avoid conflicts
in accessing client state during background rollbacking.
transaction::bf_abort() is modified to set has_rollback_ flag when
backgroung rollbacking has been assigned for the client
sync_rollback_complete() method has been modified to reset the backround
rollbacker flag
- fixed node ID assertion in on_connect() method,
fixed "sanity checks" to allow reconnection to primary component
- fixed code duplication in on_view() method
Added a call to log_view() to do the internal initializations that
need to be done on receiveing a new view. Note however that it is not
a view *event*. Here we only need to configure the application to
comply with a new state that it has received, so that it can go on
to apply replication events and catch up with the cluster.
This patch changes wsrep::transaction::after_rollback() and
wsrep::transaction::certify_fragment() so that no client state locking
is performed while in storage service scope.
The reason for this change is to not confuse the application as to
which client context locks/unlocks a mutex. More specifically, this
caused MariaDB's safe_mutex to report "Wrong usage of mutex" warnings
as the underlying THD context was switched while using storage service.
When member joins the group and needs to receive an SST it won't
receive the corresponding menbership view event because the SST
happens after the event and will already include the effects of
all events ordered before it. The view then must be recovered from
the received state.
Minor renames and cleanups.
References codership/wsrep-lib#18
Dbsim has internal map of server objects for SST simulation.
This was mapped using server_id, which is not available
anymore when server object is constructed. Changed the dbsim to
use server name instead for internal mapping.
it on disconnect.
- Don't rely on own index from the view because the view may come from
another member (IST/SST), instead always determine own index from own ID.
Refs codership/wsrep-lib#13
There are some corner cases where keys with two parts are needed
for a transaction. Relaxed the assertion and sanity check so that
at least two key parts are needed for each key which is assigned
to a transaction.
Travis:
* Don't install all g++ versions on all build targets.
* Install addons per target to have finer control on what is needed
* Use WSREP_STRICT_BUILD_FLAGS on other targets than GCC 4.8
cmake:
* Fixed CMakeLists.txt to check only boost libraries which are
actually needed
In order to make build successful on wider number of platforms,
removed -Weffc++ from default build options. Added a new cmake
option WSREP_LIB_STRICT_BUILD_FLAGS to enable it.
Unit tests which cause streaming rollback leaked memory because
the streaming applier handle which was created for rollback
fragment handling was not released. Roll back a streaming transaction
and release applier handle appropriately in corresponding tests.
with superproject definitions.
Avoid using client_service::do_2pc() in before_commit() to
determine if 2pc is actually happening, will use transaction
states to deduce that. client_service::do_2pc() should be deprecated.
Fixed a compiler warning in db_high_priority_service.cpp.
Moved SR fragment removal for total order BFd SR transactions
into after_rollback() call to avoid deadlocking while trying
to access storage before rolling back the transaction.
* Check error code from fragment release
* Always call streaming rollback from must abort if the
transaction is in executing phase. This is needed to ensure
that rollback fragment replication happens before rollback starts
* Initiate streaming rollback from certify fragment if BF abort
happens after fragment certification.
* Release server lock temporarily when BF aborting local SR
transaction during view event processing
* Check transaction state for BF aborts in before_prepare() after
the lock has acquired after fragment removal
* Send rollback fragment only from streaming_rollback()
* Check fragment removal error code in prepare phase. It is possible
that the transaction gets BF aborted during fragment removal.
* Mark fragment certified in certify_fragment() even if the provider
returns cert failed error. With current wsrep-API error codes
it may not be possible to distinquish certification failure
and BF abort during fragment replication. This may also be a
provider bug. As a result rollback fragment may sometimes be
replicated when it would not be necessary.
* Count separately fragments certified and fragments stored in
streaming context. Storing the fragment may ultimately fail
due to BF abort even if the fragment was succesfully certified.
Therefore we need to have separate counter for certified fragments
to determine if the transaction is streaming and seqnos of fragments
which have been succesfully stored.
* Provider release is called only after succesful fragment certification
and fragment store.
* Fixed handling of write sets with rollback flag set in apply_write_set()
SR tranasctions are BF aborted or rolled back on primary view
changes according to the following rules:
* Ongoing local SR transactions are BF aborted if the processing
server is not found from the current view.
* All remote SR transactions whose origin server is not included in the
current view are rolled back.
* Enable codepath to BF abort high priority SR applier
* Pass ws_handle, ws_meta to high priority service rollback
call to allow total ordering of rollback process
* Added server_id into transaction in order to be able to stop
streaming applier during high priority BF abort
* Added missing commit fragment applying
* Don't clear fragments for replaying SR transaction
* Handle BF rollback also in after_statement() call.
* Added missing after_apply() call when handling rollback fragment.
* Fixed state changes when rollback is starated during preparing state.
