Java RMI

The Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine. RMI provides for remote communication between programs written in the Java programming language.

That is the definition of RMI provided by Oracle on this page. So, now let's have fun with RMI.

We will create two classes that act as a client and a server. The client consumes object provided by server. First we create the object which is a POJO that implements Remote and Serializable. All the methods that are accessible from client (which are public methods) should declare RemoteException.



Next we create the client. It does the following things in order: Locate remote server host which in my case is localhost, lookup User object, and then update user's address. A note here is that the update is not persisted to the object on server, it is kept locally.



Now we will take a look at the server class. The server first will create a registry at port 1099. It then creates a User object and bind it to the "user" registry. After that, it will execute infinite loop while waiting for user's interaction.

If user types 'a', the User's address is updated and the update is available for the next clients looking up for it when they call lookup() method.

If user types 'b', the User object is unbound so that an error is thrown if next clients looking up for it.

If user types 'c', the "user" registry is replaced with new object user2; this is known as rebind.

If user press 'p', it will simply write user's properties to console.

ThreadLocal

ThreadLocal is a class that lets you wrap an object inside it so that each thread accessing ThreadLocal will get its own copy of the object. Consider the following example.

Suppose I have a multithreaded application. The main purpose of each thread in the application is to modify an object through long running processes by calling so many methods (OK this is quite unrealistic example :p). Each thread has its own object to modify. We can declare the object variable in the Thread class or Runnable implementation class or pass it around the methods but obviously it is not a good practice and not always can be done. To overcome this, we can use ThreadLocal.

Images below show us how to implement this: First we have the object to be manipulated, in this case it is a POJO.



Next, we will create a main class which has three threads. Each thread is intended to manipulate a User.



Now we will see the Runnable class to manipulate the object. In the run() method we can see that we modify the user's address in another method and try to see if the changes are persisted correctly. In real life, this is the long-running process that calls many methods to modify the User object.



It's the time to see the ThreadLocal variable in UserFactory class. In the UserFactory class we create a ThreadLocal variable and implement it anonymously. The initialValue() is called only once so it is the best place to initiate everything. All other method's names are quite self-explanatory.



The results are shown below. We can see that each thread has exactly one copy of the User object and the User in each thread is modified correctly. ThreadLocal is very convenient to store an object to be accessible throughout the thread.

Yet Another SQL Best Practice

Just happened to know a best practice to replace NOT IN in SQL using LEFT OUTER JOIN. Consider the following query:

SELECT * FROM a WHERE a.pk NOT IN (SELECT fk_a FROM b)

Nothing's wrong with query above; however, we can make it better by replacing it with:

SELECT * FROM a LEFT OUTER JOIN b ON a.pk = b.fk_a WHERE b.fk_a IS NULL

This can be explained like this: Left outer join uses table "a" as the master. Each row in table "a" will be matched with each row in table "b". If there is no row matched in table "b" for table "a", null will be returned. See an example below:

a b
1 1
2 null
3 3
4 null
5 5

Now in the WHERE clause we state that we are only interested in rows where b.fk_a is null which means we get all rows in table "a" that has not matched any row in table "b".