Refactor your applications to Kubernetes

Tackle-DiVA helps developers understand database operations and transaction processes inside applications.
65 readers like this.
Tips and gears turning

Application modernization developers must be able to understand database operations and transaction processes inside applications precisely. Tackle-DiVA (Data-intensive Validity Analyzer) is an open source data-centric Java application analysis tool in the Konveyor Tackle project that aims at refactoring applications to Kubernetes.

This article gives an overview of Tackle-DiVA and presents example instructions and analysis results.

What is Tackle-DiVA?

Tackle-DiVA is built using Java and Python and operated using a command-line interface. It imports target Java application source files and provides analysis results as files.

Breaking down this diagram:

  • Service entry inventory analysis extracts a list of Java classes for implementing public APIs.
  • Database inventory analysis exports a list of database tables operated by an application.
  • Transaction inventory extracts a set of transaction processes.
  • Code-to-database dependency analyzes which Java class operates which database table.
  • The database-to-database and transaction-to-transaction dependency analyses find clues for transforming parallel executions.
  • Finally, transaction refactoring recommendation analysis shows parallel executable transactions from original sequential executions.

Try it out!

It is easy to get started with Tackle-DiVA. It makes full use of Docker containers, and the only prerequisite is a Docker-runnable environment, such as RedHat Enterprise Linux, Ubuntu, or macOS.

Once you have Docker available on your machine, run:

$ cd /tmp
$ git clone && tackle-diva
$ docker build . -t diva

This builds Tackle-DiVA and packs it as a Docker image. Tackle-DiVA is now ready to use on your machine.

The next step is to prepare source codes of your target Java applications. I'll use the DayTrader application as an example:

$ cd /tmp
$ git clone

The final step is to execute the diva_docker command by attaching the full directory path:

$ cd /tmp/tackle-diva/distrib/bin/
$ ./diva_docker /tmp/sample.daytrader7/

This creates the tackle-diva/distrib/output directory and stores the analysis result files:

$ ls /tmp/tackle-diva/distrib/output
contexts.yml            transaction.json
database.json           transaction.yml         transaction_summary.pdf

Explore the analysis results

Take a look at some analysis results for the DayTrader application.

The service entry inventory result is stored in the contexts.yml file. It finds that the TradeAppServlet.init class/method plays a key role in service entries for the login and register actions:

- entry:
   - ""
   - "login"
- entry:
   - ""
   - "register"

The database inventory analysis exports six database tables in the database.json file. These tables are used in the DayTrader application:

 "/app": [

The transaction inventory analysis result is dumped into the transaction.json and .yml files, but it's better to check the transaction_summary.pdf file when looking through transactions. The following transaction consists of six SQL operations to two database tables: holdingejb and orderejb:

The transaction.json and .yml files also contain code-to-database dependency analysis results. The following shows how the TradeDirect class invokes query operations to two database tables, accountprofileejb and accountejb:

"stacktrace" : [
  "method" : "<src-method: < Source,
              Ljava/sql/PreparedStatement; >>",
  "file" : "/app/daytrader-ee7-ejb/src/
  "position" : " [1935:15] -> [1935:41]"
"sql" : "select * from accountprofileejb ap where ap.userid = (
            select profile_userid from accountejb a where a.profile_userid=?)"

The database-to-database dependency analysis result is located in the and .pdf files. The accoutprofileejb and accoutejb database tables have a mutual-query relationship:

The transaction-to-transaction dependency analysis results are found in the and .pdf files. Two transactions have a dependency on the orderejb database table. The upper transaction updates the table, and the lower transaction queries it:

Finally, parallel executable transactions are shown in the and .pdf files, resulting from the transaction refactoring recommendation analysis. In this example, two transactions in the lower part can be executed in parallel after the upper transaction processing completes, which helps keep data consistency due to no transaction dependencies:

Learn more

To learn more about application refactoring, check out the Konveyor Tackle site, join the community, and access the source code on GitHub.

What to read next
User profile image.
Dr. Yasuharu (Yasu) Katsuno is a Research Staff Member at IBM Research - Tokyo. His research interests include distributed transaction processing, application modernization, microservices, and distributed systems. He has a Master’s degree from Keio University and a Ph.D. degree from the University of Tsukuba.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.