Transaction control between two different applications

Navigation
2

I'm working on an application that is split into two modules, each in a language (.NET and Java).

The A (.NET) application will manipulate the records of a table while the B (Java) application will handle it at the same time.

  

Scenario: Imagine that I have a Client and Balance structure in the account.

     

When the client does not exist, both applications can register it.   In order for the client to not be duplicated in the database, a unique one was created in the database (Oracle).

So far so good, there will be no customer twice. The problem begins when both applications are moving the customer account.

Example: Imagine that the .Net application makes a $ 50 deposit. At this moment the record in the table will have 50 balance. But if at the same time of this deposit, a routine was done that removes $ 10.00 from this client's balance.

I would need to control the transaction between two applications, ie if a deposit of $ 50.00 and a cash of $ 10.00 at the same time (hypothetically speaking) was made, the client's final balance should be R $ 40.00.

The scenario I have today, the applications retrieve the customer record, perform the calculation and return the updated value to the table, but there is an overlap of the data. For example, the .NET transaction launches balance of $ 50.00 and the Java application launches $ 10.00 withdrawal at the same time. As far as the .NET application recovers the centralized registry of the client, it has 0 balance as well as the Java application as well. If the .NET application finishes first, it throws a balance of 50, and then the Java application launches a payout of 10, leaving the record in the -10 table.

Is there any way to control this between the two applications only with each application's transaction with yours? I've been thinking and imagined a scenario where there should be a service using LOCK to handle this type of operation. Can you imagine another way to solve it?

Note: It is a legacy system, changing the way the balance is stored would be virtually unfeasible.

Thanks!

    
asked by anonymous 31.07.2016 / 14:59

1 answer

0

Well, the most obvious suggestion would be to add a column to make an optimistic lock (see examples of this here and here , it's also easy to find more examples on google).

However, since this is a legacy system where it is difficult or impossible to tinker with the database structure, I think the best suggestion is as follows:

  • Create an application (let's call it X) that has exclusive access to the database and controls it uniquely.

  • The application X knows and guarantees the business rules of database usage.

  • The X application could then make available the services provided by the database through REST, webservices, sockets, etc. Importantly, X should expose only operations that allow the database to be changed or queried in ways that make sense to the system's business rules. That is, nothing to make a generic update service available or something that receives SQL statements directly.

  • Modify the other applications (let's call them A and B) so that they can only access the data through the X application. Other applications would then be summarily banned from connecting directly to the database. data.

    • This approach eliminates your fundamental problem of having two applications accessing the database at the same time. It's true that you get a new problem, which is that you need one more application to control all of this (and in a way you can say that you've turned problem A into another problem B only). However, in this X application, you have full control over data access and system business rules, something you did not have when the applications all went directly to the database. This also helps you centralize and unify business rules, thereby eliminating much duplication of efforts resulting from having the same business rules implemented in two or more different places and ensuring that the implementation of these rules is the same for all (as it will be in one place).

    Obviously this approach would give a job to be fully implemented, but it can be implemented in stages or only partially in the parts where it is needed. Choose the most critical cases (for example, the client balance change) and place it in the X application and change both the A and B applications to use the X application in this case. Then choose another feature and do the same. Do this until all the functionality is within the X application (or at least all the features you think the effort is worth doing).

    Finally, depending on how your applications are, it may be easier to choose one of them (let's say it's A) to be X and make the other one (B) access the first one. Or it may be easier to get one of them (A) and divide it into two: X and the original application A, making B access X.

    I recommend reading this question and also my reply there .

        
    31.07.2016 / 15:38
    as the moon (corona sdk) runs on android Number of rows increases after use of JOIN