that the logging was fast and failsafe in moments when the database was not
available. We were successful in developing a system that had fast response times
and was reliable. We were pleased with what we had achieved.
Then we were asked to log each user's actions to a database table along with some
specii c user‐related data. The database we were asked to use had a reputation for
being slow and for regularly crashing and restarting. This was bad news for our
fast and reliable logging system. We now had to refactor our system, taking into
consideration the unreliability of the database. Imagine what would happen if a
user interaction was being logged at the same time the database went down. The
synchronous call to the logging system would block the response to the user until
it either regained connection or timed out. The user would have to wait, which was
We did not want the user to wait for the database to respond and expose a database
error to the front end, especially considering that we were only logging statistics.
After implementing and testing all the DAO classes, we added the @Asynchronous
annotation and prepared to go live.
As usual, we were coni dent in our well‐tested deployment package, so we decided
to go home to sleep rather than spending the night with the server administrators
who were doing the deployment. The next morning we received an e‐mail advising
us that the application was live.
Soon we discovered that our server's log i les were full of errors, showing that the
database connection had been unavailable. We contacted the server administrators
and quickly discovered that the database admins had forgotten to create the log
tables in the live database. The tables were quickly created, and all was well until
the database started to suffer from performance‐related issues and had frequent
server restarts (as was expected given its reputation).
Our application had failed to persist some noncritical logs but never faltered in its
performance. Every time there was a problem with the database and the logging
failed, the user had already i nished what he was doing and didn't notice that
the logging had failed, thanks to the use of asynchronously calling the logging
Asynchronous programming is a great tool to use when separating tasks that do
not need to interact with each other.
The asynchronous pattern relies on the i re and forget approach where an operation is done in
parallel or in a way not blocking the executor thread, and the result is checked when it is ready.
Usually the asynchronous approach makes use of parallel execution. It may not be accurately
rel ected with a class diagram but may be better shown with a l ow diagram. Figure 9-1
demonstrates several asynchronous execution l ows.