CODEWITHSUNDEEP
javamultithreadingspringasynchronous
user123454321
user123454321

Reputation: 1058

Using asynchronous methods in enterprise system

I have been working on very large enterprise system for financial institution for quite some time. I have only noticed few usages of asynchronous methods (frankly speaking maybe 2 or 3). Lets say i have 3 methods: doSomething1(), doSomething2(), doSomething3();

// X = {1,2,3}
SomeResult doSomethingX() {
    // execution of this method takes 5-15 secs
}

xxx foo() {
    SomeResult result1 = doSomething1();
    SomeResult result2 = doSomething2();
    SomeResult result3 = doSomething3();
    // some code
}

So the execution of foo takes about 3x(5-15)sec = ~30sec

There is a lot of methods similar to foo in our system and I am wondering why there are not any async methods? Wouldn't just adding @Async to doSomethings() methods make it much faster? Or is it just 'we dont use threads explicitly in enterprise systems'

Upvotes: 0

Views: 60

Answers (2)

Robert Moskal
Robert Moskal

Reputation: 22553

If you are using spring, you can use the @Async annotation to doSomething(), but it's not all you have to do:

You have to return an AsyncResult from the method and you have to use Future to manage your return values. The following "code" is taken more or less whole cloth from the spring example: https://spring.io/guides/gs/async-method/: 

    Future res1 = doSomething("one");
    Future res2 =  doSomething("two");
    Future res3 = doSomething("three");

    // Wait until they are all done
    while (!(res1.isDone() && res2.isDone() && res3.isDone())) {
        Thread.sleep(10); //10-millisecond pause between each check
    }

    System.out.println(res1.get());

Thats already a fair amount of orchestration (perhaps there are better ways), but it gives you an idea of the amount of labor that will go in to handling concurrency at a low level. With complexity comes risk.

It seems to me that most folks have come to the conclusion that it's better to let the container handle such scaling issues rather than to handle them by hand. You're supposed to let the container scale your EJBs and your queue workers. There are plenty of java implementations that let you scale in this way.

Nonetheless, if you made something that took 60 seconds take 5 using a low level method like the above, go for it. You'll be a hero.

Upvotes: 0

Will
Will

Reputation: 820

It is always worth remembering that code written before you joined a project may have been written by someone who had more experience, or who had to solve a unique issue you have not seen, and after trying smarter ways had to do something that seems strange to you. Maybe there is some state you're missing that would not be in place if it was done asynchronously.

But of course, it could just be the case that either:

a) the developers didn't know about it/use it

or

b) it wasn't available at the time for whatever reason.

Enterprises certainly aren't allergic to asynchronous code, multi-threading, or anything else you may thing of.

Upvotes: 2

Related Questions