I have a several years of experience developing web applications with PHP and I've also worked with Java extensively (however never for web application development). I'm completing a large project that I've been working on for the past six months built in PHP/CodeIgniter and hosted with CloudControl (provides automatic server provisioning and scalability).
The project has gone well, and PHP served my needs - but now I'm in the beginning phase of developing a web application that will be targeted towards enterprise users and I'm considering using Java (possibly 'Grails') in conjunction with AWS Elastic Beanstalk.
My first question is: multi-threading, how often is it used in web application development for Java? With my PHP app, my server might have been required to make an API call to facebook in response to a user's request (say post to a user's wall). To avoid having my PHP process wait on the API call completing before returning to the user, I used Gearman job queing servers w/ workers to offload the work from my primary application server to a background worker.
Would a Java developer simply spin up a thread just to handle the API call and have the main process return to the user? Is this the biggest strength of Java development over PHP? Thanks!
Would a Java developer simply spin up a thread just to handle the API call and have the main process return to the user?
It depends.
If you do that, then the original thread can do something else for a bit, but unless it is designed to be event based, then it will eventually need to wait for the secondary thread to finish ... and you are back where you started. (Actually you are worse off ... because you've now got 2 threads waiting.)
In the case of a web server implemented using classical Java servlets, each user request is run on its own thread. The simple approach would be to perform the API call on the request thread. This blocks the thread, but other threads can be working on other requests while this is going on. Assuming that you have enough threads in the web container's thread pool this works fine ... though you do end up using lots of resources (memory) on thread stacks.
The most recent versions of the Java servlet specs have added support for asynchronous processing. I'm not up to speed on the details, but this would in theory allow you to disconnect a request thread from a request while the latter was doing something that took a long time. However, I'm not convinced that this would help here ... unless you had a client side implementation of the API that was similarly able to run multiple simultaneous requests in parallel using a small (and bounded) number of Java threads.
There are possibly other alternatives, but they could be a lot more work.
My advice would be to go for a simple solution to start with. Just do the API call on the request thread, and configure your web server to use a reasonable number of request threads.
The chances are that you will be able to get away with "wasting" some memory to get the throughput you actually need. In the longer term you might need to address that, but you will have had time to learn more about the more scalable alternatives by then.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With