DTM release 1.8.4 supports zero configuration startup, brew one-click installation

DTM released the latest version 1.8.4, the main updates are as follows:

1. Zero configuration startup, more friendly for newcomers to get started, does not rely on docker, does not rely on the database, zero dependence, zero configuration directly start
2. Support homebrew one-click installation
3. Support custom sub-transaction request header
4. Support HTTP/gRPC interceptor
5. Support custom server and database table names used in SDK

Zero configuration startup

The latest version 1.8.4, you can download the installation package of the corresponding platform (support linux, Mac, windows) on this page

https://github.com/dtm-labs/dtm/releases/tag/v1.8.4

After decompression, run it directly to start. By default, dtm uses the built-in boltdb storage engine (etcd also uses this storage engine). It will create the dtm.bolt file in the current directory, which saves the global transaction progress.

Under the new method, users no longer need docker and do not need to install the database in advance, which greatly reduces the difficulty of getting started for newcomers and can quickly start the journey of distributed transaction experience.

Under the boltdb storage engine, the function of clearing expired data is https://github.com/lsytj0413 from the community, special thanks

homebrew one-click installation

In order to make it easier for developers to use dtm, we have also released dtm to homebrew. If you are working on a mac, you only need the following simple command to install dtm

brew install dtm

This will install two commands: dtm dtm-qs, run the dtm server with the following command:

dtm

Then run the following command to initiate a simplest distributed transaction example, which simulates a distributed transaction example of cross-bank transfer

dtm-qs

You can see the TransOut and TransIn logs from the dtm-qs log, indicating that the transaction has been successfully completed

Support custom sub-transaction request header

By setting the BranchHeaders in the global transaction object, the dtm server can pass these headers to each sub-transaction. This feature can solve the problem that the sub-transaction API requires permission verification. The usage example is as follows:

    gidYes := dtmimp.GetFuncName()
    sagaYes := dtmcli.NewSaga(dtmutil.DefaultHttpServer, gidYes)
    sagaYes.BranchHeaders = map[string]string{
        "test_header": "test",
    }
    sagaYes.WaitResult = true
    sagaYes.Add(busi.Busi+"/TransOutHeaderYes", "", nil)
    err := sagaYes.Submit()

There are more examples under dtm-labs/dtm-examples, including examples of HTTP and gRPC protocols

Support HTTP/gRPC interceptor

The dtm SDK adds support for HTTP/gRPC interceptors. If you need to customize related requests in depth, you can customize them through the following three interceptor interfaces

func OnBeforeRequest(middleware func(c *resty.Client, r *resty.Request) error)

func OnAfterResponse(middleware func(c *resty.Client, resp *resty.Response) error)

func AddUnaryInterceptor(interceptor grpc.UnaryClientInterceptor)

Support custom server and database table names used in SDK

The following functions are added to the SDK to allow customizing the table name of the sub-transaction barrier:

SetBarrierTableName

The server side supports customizing the table names of the global transaction table and branch transaction operation table. The configuration name is:

Store.TransGlobalTable
Store.TransBranchOpTable

project address

For more theoretical knowledge and practice of distributed transactions, you can visit the following projects and public accounts:

https://github.com/dtm-labs/dtm , welcome to visit, and star support us.

Pay attention to the [Distributed Affairs] official account, get more knowledge about distributed affairs, and join our community at the same time