Java EE / EJB vs Spring for managing distributed transactions with multiple database clusters

I have a requirement to create a prototype (running on a J2EE-compatible MySQL application server) demonstrating the following

  • Demonstrate the ability to distribute a transaction across multiple databases located on different sites around the world (replication of managed application data)

  • Demonstrate the ability to write a transaction to a database by selecting multiple database clusters located in different locations. The choice of database to record depends on the user's location. (Data replication with a managed database)

I have the option to select either the Spring stack or the Java EE stack (EJB, etc.). It would be useful to know your opinion on which stack is best to support distributed transactions across multiple database clusters.

If possible, could you also point me to any resources that you think will be useful to learn how to implement the above using either of the two stacks. I think that seeing examples of both will help to understand how they work, and will probably be in a better position to decide which stack to use.

I have seen many sites browsing Google, but most of them seem to be out of date (i.e. pre EJB 3 and pre Spring 3)

thanks

+4
source share
1 answer

I would use the JavaEE stack as follows:

  • configure XA DataSource for each database server
  • according to the user's location, the Stateless EST file looks for the corresponding DataSource and receives a connection from it.
  • when translating a transaction to all servers, Stateless EJB must iterate through all configured data sources to execute one or more queries on them, but in one transaction

In the event of a technical failure, the transaction is rolled back to all relevant servers. In the event of a business failure, the code can cause a rollback due to context.setRollbackOnly() .

This way, you first benefit from JavaEE's automated distributed transaction, and then you can use more complex templates if you need to manage the transaction manually.

BUT, the more servers you have credited to your transaction, the longer the two-phase commit operation will be, moreover, if you have a high delay between systems. And I doubt that MySQL is the best relational database to perform such complex distributed transactions.

+1
source

Source: https://habr.com/ru/post/1392912/


All Articles