Applying a lock over a call to a method performing network transactions can be problematic. Depending on the speed and reliability of the connection, synchronization can stall the program indefinitely causing a huge performance hit. At other times, it can result in temporary or permanent deadlock.

Noncompliant Code Example

This noncompliant code example involves the method sendPage() which sends a Page object containing information being passed between a client and server. The method is synchronized to protect access to the array pageBuff. Calling writeObject within the synchronized sendPage can lead to a deadlock for high latency or lossy network connections.

// Class Page is defined separately. It stores and returns the Page name via getName()

public final boolean SUCCESS = true;
public final boolean FAILURE = false;
Page[] pageBuff = new Page[MAX_PAGE_SIZE];

public synchronized boolean sendPage(Socket socket, String pageName){
  try{
    // Get the output stream to write the Page to
    ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());

    Page targetPage = null;

    // Find the Page requested by the client
    for(Page p : pageBuff){
      if(p.getName().compareTo(pageName) == 0)
        targetPage = p;
    }

    // Page requested does not exist
    if(targetPage == null)
      return FAILURE;

    // Send the Page to the client
    out.writeObject(targetPage);
    out.flush();
    out.close();
  } catch(IOException io){ /* handle exception */ }
  return SUCCESS;
}

Compliant Solution

One compliant solution entails separating the actions into a sequence of steps:

In the following example, the synchronized method getPage() is called from SendReply to find the appropriate Page requested by the client from the Page array pageBuff. The method sendReply() in turn calls the unsynchronized method sendPage() to deliver the Page.

public boolean sendReply(Socket socket, String pageName){
  Page targetPage = getPage(pageName);

  if(targetPage == null)
    return FAILURE;

  return sendPage(socket, targetPage);
}

private synchronized Page getPage(String pageName){
  Page targetPage = null;

  for(Page p : pageBuff){
    if(p.getName().equals(pageName))
      targetPage = p;
  }

  return targetPage;
}

public boolean sendPage(Socket socket, Page page){
  try{
    // Get the output stream to write the Page to
    ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());

    // Send the Page to the client
    out.writeObject(page);
    out.flush();
    out.close();
    return SUCCESS;
  }catch(IOException io){
    // handle exception else return failure
    return FAILURE;
  }
}

General recommendations for correct use of locks and synchronization appear in CON00-J. Use synchronization judiciously.

Risk Assessment

If monitor regions such as synchronized methods and statements contain network transactional logic, temporary or permanent deadlocks may result.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

CON37- J

low

probable

high

P2

L3

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Grosso 01|AA. Java References#Grosso 01]\] [Chapter 10: Serialization|http://oreilly.com/catalog/javarmi/chapter/ch10.html]
\[[JLS 05|AA. Java References#JLS 05]\] [Chapter 17, Threads and Locks|http://java.sun.com/docs/books/jls/third_edition/html/memory.html]
\[[Rotem 08|AA. Java References#Rotem 08]\] [Falacies of Distributed Computing Explained|http://www.rgoarchitects.com/Files/fallacies.pdf]

CON36-J. Always synchronize on the appropriate object      09. Concurrency (CON)      CON38-J. Ensure atomicity of thread-safe code