seata1.5.2主键中带有逗号导致获取全局锁lock key值错误

[SyngnaQiao]

• I have searched the issues of this repository and believe that this is not a duplicate.

Ⅰ. Issue Description

主键中带有逗号，获取全局锁错误

Ⅱ. Describe what happened

seata日志:

09:43:43.268  INFO --- [verHandlerThread_1_33_500] i.s.s.coordinator.DefaultCoordinator     : Begin new global transaction applicationId: mom-mes-nei-biz,transactionServiceGroup: mom_tx_group, transactionName: generateNextValuesCommitImmediately(com.foreverwin.mom.mes.nei.horizon.business.common.dto.GenerateNextNumberRequest),timeout:60000,xid:192.168.5.101:8091:4846209188163301399
09:43:43.290  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301399,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_next_number:NextNumberBO:KS,D01
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.320  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301399,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_next_number:NextNumberBO:KS,D01
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.320  INFO --- [verHandlerThread_1_35_500] i.seata.server.coordinator.AbstractCore  : Register branch successfully, xid = 192.168.5.101:8091:4846209188163301399, branchId = 4846209188163301400, resourceId = jdbc:mysql://mom-mysql:3306/momx_mes ,lockKeys = z_next_number:NextNumberBO:KS,D01
09:43:43.340  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301399,extraData=null
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.358  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.358  INFO --- [verHandlerThread_1_37_500] io.seata.core.lock.AbstractLocker        : Global lock on [z_sfc_production:SfcProductionBO:KS] is holding by 4846209188163301386
09:43:43.360  INFO --- [verHandlerThread_1_37_500] i.s.c.e.AbstractExceptionHandler         : this request cannot acquire global lock, you can let Seata retry by setting config [client.rm.lock.retryPolicyBranchRollbackOnConflict] = false or manually retry by yourself. request: xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
09:43:43.389  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.389  INFO --- [verHandlerThread_1_38_500] io.seata.core.lock.AbstractLocker        : Global lock on [z_sfc_production:SfcProductionBO:KS] is holding by 4846209188163301386
09:43:43.391  INFO --- [verHandlerThread_1_38_500] i.s.c.e.AbstractExceptionHandler         : this request cannot acquire global lock, you can let Seata retry by setting config [client.rm.lock.retryPolicyBranchRollbackOnConflict] = false or manually retry by yourself. request: xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
09:43:43.417  INFO --- [verHandlerThread_1_39_500] io.seata.core.lock.AbstractLocker        : Global lock on [z_sfc_production:SfcProductionBO:KS] is holding by 4846209188163301386
09:43:43.416  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
,clientIp:127.0.0.1,vgroup:mom_tx_group
09:43:43.417  INFO --- [verHandlerThread_1_39_500] i.s.c.e.AbstractExceptionHandler         : this request cannot acquire global lock, you can let Seata retry by setting config [client.rm.lock.retryPolicyBranchRollbackOnConflict] = false or manually retry by yourself. request: xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
09:43:43.455  INFO --- [     batchLoggerPrint_1_1] i.s.c.r.p.server.BatchLogHandler         : SeataMergeMessage xid=192.168.5.101:8091:4846209188163301396,branchType=AT,resourceId=jdbc:mysql://mom-mysql:3306/momx_mes,lockKey=z_sfc_production:SfcProductionBO:KS,SJA122208A01P1
,clientIp:127.0.0.1,vgroup:mom_tx_group

Ⅲ. Describe what you expected to happen

Ⅳ. How to reproduce it (as minimally and precisely as possible)

1. xxx
2. xxx
3. xxx

Ⅴ. Anything else we need to know?

Ⅵ. Environment:

• JDK version : 1.8
• Seata version: 1.5.2
• OS : windows
• Others:

[funky-eyes]

This bug has been on our radar before, but if it's fixed it won't be backwards compatible which is a problem, do you have any good ideas?

[SyngnaQiao]

This bug has been on our radar before, but if it's fixed it won't be backwards compatible which is a problem, do you have any good ideas?

可不可以把主键的分隔符做成可配置的，默认是逗号，如果有配置就按配置的

[funky-eyes]

This bug has been on our radar before, but if it's fixed it won't be backwards compatible which is a problem, do you have any good ideas?

可不可以把主键的分隔符做成可配置的，默认是逗号，如果有配置就按配置的

已在运行中的事务如何解决？贸然替换分隔符可能造成数据的脏写，导致无法回滚（如果业务侧没有抛业务上的异常，二阶段回滚概率不大倒是不影响）。

[Bughue]

This bug has been on our radar before, but if it's fixed it won't be backwards compatible which is a problem, do you have any good ideas?

可不可以把主键的分隔符做成可配置的，默认是逗号，如果有配置就按配置的

已在运行中的事务如何解决？贸然替换分隔符可能造成数据的脏写，导致无法回滚（如果业务侧没有抛业务上的异常，二阶段回滚概率不大倒是不影响）。

要做得严谨的话感觉要加版本号概念了

[laywin]

i feel best way to solve the problem is to encode the lock key, so user have no feel.

to solve the compatible problem:

in client:
check the server version to decide to encode lock key

in server:
check the client version to decide to decode lock key

[laywin]

i feel best way to solve the problem is to encode the lock key, so user have no feel.

to solve the compatible problem:

in client: check the server version to decide to encode lock key

in server: check the client version to decide to decode lock key

@funky-eyes please help check the logic 😊， may be i can make another contribute , haha.

[ggbocoder]

I have two solutions.

Using escape characters: On the client side, insert an escape character "" before the "," in primary keys containing ",". For example, "NextNumberBO:KS,D01" becomes "NextNumberBO:KS,D01". On the server side, when splitting, do not split on ",".

On the client side, replace "," in the primary key with a rarely used symbol. On the server side, replace it back during processing.

I believe these two solutions are compatible with previous versions.

---

我有两个方案。

1.使用转义符，在客户端，对于含有“，”的主键插入转义符“\”,例如，"NextNumberBO:KS,D01"--》"NextNumberBO:KS\,D01"，在服务端切分的时候对于“\,”不进行切分

2.在客户端，将主键中的“，”替换为某个不常用的符号，在服务端处理时再替换回来

我认为这两个方案可以与以往版本兼容。