OReilly: Java Enterprise Best Practices by By

Author:By
Language: eng
Format: epub
ISBN: 0-596-00384-6
Publisher: O'Reilly
Published: 2011-10-04T19:40:09.825439+00:00

Example 6-2. BackgroundCallQueue.java and BackgroundCallQueueImpl.java

public interface BackgroundCallQueue { public void addCall(RemoteMethodCall callToAdd); } public class BackgroundCallQueueImpl implements BackgroundCallQueue { private LinkedList _pendingCalls; private thread _dispatchThread; public BackgroundCallQueueImpl ( ) { _stopAcceptingRequests = false; _pendingCalls = new LinkedList( ); _dispatchThread = new Thread(this, "Background Call Queue Dispatch Thread"); _dispatchThread;.start( ); } public synchronized void addCall(RemoteMethodCall callToAdd) { _pendingCalls.addCall( ); notify( ); } public void run( ) { while (true) { RemoteMethodCall call = waitForCall( ); if (null!=call ) { executeCall(call); } } } private synchronized RemoteMethodCall waitForCall( ) { while (0== _pendingCalls.size( )) { wait( ); } return (RemoteMethodCall) _pendingCalls.removeFirst( ); } private void executeCall(RemoteMethodCall call) { // . . . } }

This isn't very complicated code, but it does offer two very significant advantages over synchronous method calls. The first is that it decreases the time a main thread spends sending remote messages. Imagine, for example, that a user clicks on a button, and, as a result of that click, the server needs to be told something. If you use a synchronous method call, the button processing time (and, hence, the perceived performance of the application) will include the time spent sending the remote method call (and the time the server spends processing the call). If you can make the call asynchronously, in a background thread, the application isn't any faster or more efficient, but the user thinks it is.

The second reason is that, once you've moved to a model where requests are dropped off into a queue, you can tweak the queue and make performance improvements without altering most of the client code. For example, if you are making a lot of calls to a single method on a server, you can group these calls and make them in a single call. For example, instead of 100 calls to:

server.patientGivenMedication(Patient patient, Medication medication, long time, HealthCareProvider medicationSource);

you might have 1 call to:

server.patientsGivenMedication(ArrayList medicationEvents);

Because each remote method call contains information about all the relevant classes involved, this will dramatically reduce both marshalling time and bandwidth. Instead of marshalling and sending information about the Patient class 100 times, you will send it only once.

There are two major downsides to putting messages in a background queue. The first is that your code will be harder to debug. Decoupling the source of the remote method call from the time the remote call is made makes it harder to trace the source of logical errors. For example, if a command object has the wrong value for an argument, it's harder to track down the source of the error.

The second problem with putting messages in a background queue is that it's harder to report failures (and harder to respond to them). If a user clicks a button and therefore thinks of an operation as "done," it can be disconcerting for him to find out later on that the operation failed.

Given all this, the question is: when should you use asynchronous messaging? Here are three indicators that a method can be put safely into a background queue:

If the method returns void and throws no exceptions (other than RemoteException).

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.