GWT - блок синхронизации на стороне сервера

Question

Я хочу, чтобы сервер выполнял определенную часть кода служебного импонента для одного клиента за раз, поточно-безопасный; и последовательно. Вот часть реализации службы на стороне сервера, которая делает это:

public BorcData getBorcData(String userId) throws GeneralException, EyeksGwtException 
{ 
     StoredProcedure sp = DALDB.storedProcedure("BORCBILDIRIM_GETMUKDATA_SP"); 
     DALResult spResult; 
     Row spRow; 
     String vergiNo; 
     String asamaOid; 

     synchronized (ServerUtility.lock_GeriArama_GetBorcData_GetMukDataSP) 
     { 
      String curOptime =CSDateUtility.getCurrentDateTimeToSave(); 

      sp.addParam(curOptime); 
      spResult = sp.execute(); 

      if (!spResult.hasNext()) 
      { 
       throw new GeneralException("53", ""); 
      } 
     } 

Вы видите синхронизированный блок. Объект, который я использую для замка определяется как:

public static Object lock_GeriArama_GetBorcData_GetMukDataSP = new Object(); 

Моей проблема: Я думаю, что я видел, что в то время как клиент ждет, чтобы выполнить этот синхронизированный блок в течение длительного времени, некоторые другие клиенты называют эту услугой и выполнил этот блок, не вставая и продолжая. Первый клиент все еще ждал.

Я знаю, что на стороне сервера работает чистая Java. Возможно ли, что серверная сторона несправедлива по отношению к клиентам и не запускает запрос самого длинного ожидающего клиента?

EDIT: Собственно; справедливость даже не является реальной проблемой. Иногда клиенты выглядят так, будто они просто зависают в этой синхронизированной части; ожидая вечно, чтобы служба закончилась.

Answer 1

Сначала ваш замок Объект всегда должен быть объявлен final. Это не устраняет никаких проблем, но это говорит вам, если вы сделали что-то неправильно (например, установили блокировку для другой блокировки).

Одним из способов обеспечения справедливости является использование ReentrantLock, инициализированного с помощью истинного (справедливого планирования). Это гарантирует, что клиенты не будут вешать бесконечно, но выполняются в порядке FIFO. Хорошая вещь заключается в том, что это требует лишь незначительных изменений в код, заменив все эти синхронизированные блоки:

lock.lock(); 
try { 
    // previous code 
} finally { 
    lock.unlock(); 
} 

наконец это просто мера безопасности, если какая-либо часть внутри сгенерирует исключение.

Кроме того, ваш код выглядит отлично, поэтому проблема, скорее всего, будет в БД и не вызвана использованием синхронизации вообще.

Answer 2

Многопоточность в java не гарантирует последовательное выполнение.

Читать статью: http://www.javaworld.com/javaworld/jw-07-2002/jw-0703-java101.html Полезно знать, как планируются потоки.