What’s New in Hmily 2.1.1? A Deep Dive into the New Architecture and Features

Hmily 2.1.1 Released with New Architecture

Thanks to the community for continuous support. In this version the project has been fully refactored, functional modules are logically separated, a configuration center is added, the underlying storage structure is adjusted, bugs are fixed, and new features are introduced.

Architecture Overview

Features

High reliability : supports rollback on transaction exceptions, timeout recovery, and prevents transaction hanging in distributed scenarios.

Ease of use : provides zero‑intrusion integration with Spring‑Boot and Spring‑Namespace.

High performance : decentralized design fully merges with business systems and naturally supports cluster deployment.

Observability : multiple metrics for performance monitoring and an admin UI for display.

Multiple RPCs : supports Dubbo, SpringCloud, Montan, sofa‑rpc and other popular RPC frameworks.

Log storage : supports MySQL, Oracle, MongoDB, Redis, Zookeeper, etc.

Complex scenarios : supports nested RPC transaction calls.

Refactored Parts

Module division :

Extracted a ready‑to‑use SPI custom module.

Defined SPI modules for multiple transaction‑log storage methods.

Defined SPI modules for multiple transaction‑log serialization methods.

Added a configuration center supporting Nacos, Apollo, Zookeeper and dynamic refresh.

Added a metrics module for runtime monitoring.

Extracted the core transaction execution module.

Extracted multi‑RPC support modules.

Extracted Spring and Spring‑Boot support modules.

Dependency versions :

Guava upgraded to 29.0.

Curator upgraded to 5.1.0.

Code quality :

Strict Checkstyle enforcement for clean, elegant code.

Openness :

The community follows principles of simplicity, joy, and harmony.

Goal :

Provide a highly available, high‑performance, easy‑to‑use, financial‑grade distributed transaction solution.

Bug Fixes

Dubbo framework does not support annotation usage (spring‑boot‑starter‑dubbo).

Motan framework does not support annotation usage.

Thread switching issue when using Feign with Hystrix in Spring‑Cloud.

Serialization exceptions for transaction logs in extreme cases.

Try‑phase timeout causing transaction hanging.

Confirm and cancel phase exceptions not correctly recovered.

Support for both synchronous and asynchronous transaction‑log storage modes.

User Guide and Upgrade Steps

For Hmily users, three steps are enough to enable flexible transactions between RPC services:

Reference the Hmily JARs for the required RPC.

Add Hmily configuration.

Annotate the RPC interface method with @Hmily.

Dependency Changes

Upgrade the version to 2.1.0. Example for Dubbo:

<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>hmily-annotation</artifactId>
    <version>2.1.0</version>
</dependency>

Provider dependency (for Dubbo < 2.7):

<dependency>
    <groupId>org.dromara</groupId>
    <artifactId>hmily-dubbo</artifactId>
    <version>2.1.0</version>
</dependency>

Hmily Configuration Changes

Version 2.1.0 adds the hmily-config module, supporting local and registry modes. Create hmily.yml under resources (or specify via -Dhmily.conf or user.dir). Configuration priority: -Dhmily.conf > user.dir > resources. Example local mode configuration:

server:
  configMode: local
  appName: account-dubbo
config:
  appName: account-dubbo
  serializer: kryo
  contextTransmittalMode: threadLocal
  scheduledThreadMax: 16
  scheduledRecoveryDelay: 60
  scheduledCleanDelay: 60
  scheduledPhyDeletedDelay: 600
  scheduledInitDelay: 30
  recoverDelayTime: 60
  cleanDelayTime: 180
  limit: 200
  retryMax: 10
  bufferSize: 8192
  consumerThreads: 16
  asyncRepository: true
  autoSql: true
  phyDeleted: true
  storeDays: 3
  repository: mysql
repository:
  database:
    driverClassName: com.mysql.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/hmily?useUnicode=true&characterEncoding=utf8
    username: root
    maxActive: 20
    minIdle: 10
    connectionTimeout: 30000
    idleTimeout: 600000
    maxLifetime: 1800000

For Nacos configuration center, place the configuration under Nacos with the following structure:

hmily:
  server:
    configMode: nacos
    appName: xxxxx
remote:
  nacos:
    server: 192.168.3.22:8848
    dataId: hmily.properties
    group: DEFAULT_GROUP
    timeoutMs: 6000
    fileExtension: yml
    passive: true

For Apollo configuration center, use a similar structure with apollo under remote.

Annotation Usage Changes

Previously only @Hmily was needed on both interface and implementation. Now the interface method keeps @Hmily to mark a distributed transaction, while the implementation method must use @HmilyTCC and specify confirmMethod and cancelMethod.

Example (Dubbo)

public interface HelloService {
    @Hmily
    void say(String hello);
}

public class HelloServiceImpl implements HelloService {
    @HmilyTCC(confirmMethod = "sayConfirm", cancelMethod = "sayCancel")
    public void say(String hello) {
        System.out.println("hello world");
    }
    public void sayConfirm(String hello) { System.out.println("confirm hello world"); }
    public void sayCancel(String hello) { System.out.println("cancel hello world"); }
}

Example (Spring Cloud)

@FeignClient(value = "hello-service")
public interface HelloService {
    @Hmily
    @RequestMapping("/hello-service/sayHello")
    void say(String hello);
}

@RestController
public class HelloController {
    private final HelloService helloService;
    @Autowired
    public HelloController(HelloService helloService) { this.helloService = helloService; }
    @RequestMapping("/sayHello")
    public void payment(String hello) { helloService.say(hello); }
}

public class HelloServiceImpl implements HelloService {
    @HmilyTCC(confirmMethod = "sayConfirm", cancelMethod = "sayCancel")
    public void say(String hello) { System.out.println("hello world"); }
    public void sayConfirm(String hello) { System.out.println("confirm hello world"); }
    public void sayCancel(String hello) { System.out.println("cancel hello world"); }
}

Transaction Log Storage Structure Changes

The framework now initializes storage automatically; users do not need to handle it manually.

Next Version

Architecture adjustments will make supporting additional modes easier; the upcoming TAC (try‑auto‑cancel) mode will simplify usage by removing the need to implement confirm and cancel methods.

Support for brpc users.

Support for tars‑rpc users.

Community Contribution

We follow the principle of "harmony, joy, code first". If you have ideas and want to contribute, join us:

GitHub: https://github.com/dromara/hmily Gitee: https://gitee.com/shuaiqiyu/hmily QQ group:

162614487