Hi, thanks for the hint using the control.sh script. It looks like the server node with .111 IP address is having some very old transactions:
Matching transactions: TcpDiscoveryNode [id=78b6df9f-7b77-46ea-9aef-a1b61918b258, addrs=[110.10.123.111], order=1, ver=2.8.1#20200521-sha1:86422096, isClient=false, consistentId=3d51530f-0dec-46da-98cb-eb550c860777] Tx: [xid=93724cf8971-00000000-0d9e-4326-0000-000000000001, label=null, state=MARKED_ROLLBACK, startTime=2021-05-24 06:22:10.778, duration=3224128, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=74, minorTopVer=0], timeout=9990, size=0, dhtNodes=[], nearXid=f0724cf8971-00000000-0d9e-4326-0000-00000000004a, parentNodeIds=[75431074]] Tx: [xid=7219dcbf971-00000000-0d9e-452c-0000-000000000001, label=null, state=MARKED_ROLLBACK, startTime=2021-06-23 13:12:53.094, duration=607486, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=592, minorTopVer=0], timeout=10000, size=0, dhtNodes=[], nearXid=f119dcbf971-00000000-0d9e-452c-0000-0000000001d9, parentNodeIds=[458bca81]] Tx: [xid=a1480fb5a71-00000000-0d9e-4593-0000-000000000001, label=null, state=PREPARING, startTime=2021-06-30 10:51:37.874, duration=11161, isolation=READ_COMMITTED, concurrency=OPTIMISTIC, topVer=AffinityTopologyVersion [topVer=695, minorTopVer=0], timeout=0, size=1, dhtNodes=[78b6df9f], nearXid=a1480fb5a71-00000000-0d9e-4593-0000-000000000001, parentNodeIds=[78b6df9f]] TcpDiscoveryNode [id=5eb48408-a239-4a92-9fb2-7903407975ad, addrs=[110.10.123.87], order=688, ver=2.8.1#20200521-sha1:86422096, isClient=true, consistentId=5eb48408-a239-4a92-9fb2-7903407975ad] Tx: [xid=e95d3fb5a71-00000000-0d9e-4593-0000-0000000002b0, label=null, state=PREPARING, startTime=2021-06-30 13:57:39.511, duration=0, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC, topVer=AffinityTopologyVersion [topVer=695, minorTopVer=0], timeout=0, size=1, dhtNodes=[78b6df9f], nearXid=e95d3fb5a71-00000000-0d9e-4593-0000-0000000002b0, parentNodeIds=[5eb48408]] Command [TX] finished with code: 0 What happens if I would kill these two transactions that are in MARKED_ROLLBACK state but look like they never finished? Is it safe to kill them? Thanks! On 30.06.21 15:20, Zhenya Stanilovsky wrote:
Hi, first of all you need to know who is holding a lock, check [1] command. [1] https://ignite.apache.org/docs/latest/tools/control-script#transaction-management <https://ignite.apache.org/docs/latest/tools/control-script#transaction-management> Hi all, I have the situation that at least one DB row of my persistent cache seems locked and I can't change it anymore. Everytime I want to change it using SQL a TransactionTimeoutException happens like this: class org.apache.ignite.transactions.TransactionTimeoutException: Failed to acquire lock within provided timeout for transaction [timeout=10000, tx=GridNearTxLocal[xid=cc2d4db5a71-00000000-0d9e-4593-0000-0000000002b6, xidVersion=GridCacheVersion [topVer=228476307, order=1625038312140, nodeOrder=694], nearXidVersion=GridCacheVersion [topVer=228476307, order=1625038312140, nodeOrder=694], concurrency=PESSIMISTIC, isolation=REPEATABLE_READ, state=MARKED_ROLLBACK, invalidate=false, rollbackOnly=true, nodeId=62e91173-e912-49d5-b238-e95f8fe38314, timeout=10000, startTime=1625051540461, duration=10034, label=null]] However, the system continues to run and other objects in the cache can be added and changed. Is there a way to unlock this particular entry? Thanks!
