2024-12-07 13:13
@杜福忠 可能是我没描述清楚，DDL无所谓。主要是执行DDL，会让DDL执行之前对数据库的update强制提交，后面如果业务出现错误，要回滚，只能回滚DDL之后的update操作。DDL语句前面对数据库的update操作就不回滚了。
2024-12-05 11:33
@HingLo 如果你真需要保留历史上传文件记录，还是考虑引入OSS吧，minio是个不错的选择。既可以保留历史记录，还能存海量文件。并且可以解决后端集群部署的时候，读文件的问题。
2024-11-29 15:56
@JFinal 提到sql注入，有没有好的解决方案？或则jfinal提供一个预防sql注入的功能？最近被sql注入搞的头大。
2024-11-17 14:32
@杜福忠 市面上唯一能上生产的就是seata，但它好像只支持dubbo的rpc框架。我的rpc是基于thrift自己实现的。
2024-11-13 09:53
@杜福忠 杜总有空能不能研究一下，如果是在不同的jvm进程里呢？有没有解决方案，我是在这个地方卡住了。其实再说清楚一点，我是在这一台机器的jvm进程里通过rpc（tcp协议）调另一台机器的jvm进程下的一个方法。所以，我想必须要有一个事务协调器角色，所有事务都和事务协调器通信，告诉协调器自己是否ok，如果所有都ok，由协调器去控制所有xa事务提交，否则，就控制所有事务回滚。我理解是事务发起者先生成一个id，告诉事务协调器，然后把这个id和自己的xid发给事务协调器，调用rpc的时候，把这个id传递过去，rpc方法拿到这个id和自己的xid也去事务协调器注册自己的事务，协调器就可以把所有同一id的xid组成一个事务，然后每个进程里的xa事务都告诉协调器，自己是ok还是不ok，由协调器统一提交和回滚。到这里我弄不下去了。搁置了有快一年的时间了。
2024-11-12 17:48
如果是同一个线程，引入atomikos或则btm也是可以轻松解决多数据源xa事务的问题。但最麻烦的还是如果在多个线程里，xa事务的问题。
2024-11-12 17:40
集群模式是最适合的模式。只不过有时候有些场景不得不使用微服务（[不得不]这个词可能有点夸张）。比如我们业务场景，有财政专网和银行专网，那访问财政和银行的代码就必须通过微服务访问。当然单独在前置机部署一个web应用服务，提供http服务也是没问题的。
2024-10-25 18:06
@山东小木 不是的，传的json或则字符串都在data：里。我是想自定义event，就像complete方法里拼接了event:complete\ndata:xxxx\n\n那样，有些场景下是需要这个自定义event的。另外，你那里微信小程序接收SSE是开启enableChunk实现的吗？听说这种方式在https下，会一直等所有数据收到才一次性触发接收事件，打字机效果就没有了。不知道你那里测试过这种场景没。
