Some spider XA operations, most critically XA PREPARE, through either explicit or internal XA, keep the mysql.spider_xa_member locked while executing commands on backends.
During that time, no other spider XA transaction is able to XA PREPARE or XA COMMIT, as they are waiting for the table lock.

Considering the case of XA PREPARE (through spider_internal_xa_prepare):
It keeps the table locked while executing XA END followed by XA PREPARE, on each involved backend, sequentially.
That can be particularly bad if, for example:

1. the latency between spider and backends is non-negligible
2. multiple backends are involved
3. the backend thread or connection somehow gets killed/stuck, and spider_net_read_timeout is set too high (default seems to be 600 seconds).

This behavior limits throughput by latency and in the worst case (#3) may block other transactions for a long time.

Other functions which seem to do something similar are spider_internal_xa_commit_by_xid and spider_internal_xa_rollback_by_xid.