Java：在多线程和事务性环境中运行DAO类

Question

I am calling a DAO class from multithreaded environment that fires a select query to get a row ( get a ticketId) from the table and then update the same row (with a customerId). This happens in the same transaction. My database is SQL Server. When I fire the select query I try to put a row level lock (WITH ROWLOCK) so that the other threads don't get the same row. My DAO class is as follows (Only the important piece of code is shown here):

public void saveCustomerTicketUsingJDBC(String customerId) {
  Session session = getSession();
  //Session session = SessionFactoryUtils.getSession(getSessionFactory(), true);// Have tried this too
  try {
         session.getTransaction().begin();



        Query query1 = session.createSQLQuery("select TOP 1 * from CustomerTicket WITH (ROWLOCK) where customerId is null");
        Object[] customerTicket = (Object[])query1.uniqueResult();

             Integer id = (Integer)customerTicket[0];
             ticketId = (String)customerTicket[1];
             logger.debug("Got ticket id -->"+ticketId);



        Query query2 = session.createSQLQuery("update CustomerTicket " +
                                                "set customerId = :customerId " +
                                                "where ticketId = :ticketId");
        query2.setParameter("customerId", customerId);
        query2.setParameter("ticketId", ticketId);
        logger.debug("QUery 2 executeUpdate : customerId : "+customerId+", ticketId :"+ticketId);
        int result = query2.executeUpdate();
        logger.debug("result >"+result +", customerTicketId ----------->"+customerId+", ticketId ------------>"+ticketId);
        //session.flush();
        //session.clear();
        session.getTransaction().commit();
  } catch (Exception e) {
        logger.error("Exception while saving customer ticket-->"+e,e);
    } finally {
        if (session != null) {
            session.close();
        }
    }
}

I spawn 4 threads. What I see in the log file is that all the four threads get to the same record in the database table.

2014-02-26 22:41:29.183 DEBUG [pool-3-thread-2] CustomerTicketDAO.java:83 Got ticket id -->4
2014-02-26 22:41:29.183 DEBUG [pool-3-thread-4] CustomerTicketDAO.java:83 Got ticket id -->4
2014-02-26 22:41:29.184 DEBUG [pool-3-thread-3] CustomerTicketDAO.java:83 Got ticket id -->4
2014-02-26 22:41:29.184 DEBUG [pool-3-thread-1] CustomerTicketDAO.java:83 Got ticket id -->4

First of all this shouldn't happen, correct? I am expecting to see that each thread should get different row.

Then I see that only one thread is able to successfully update the database.

2014-02-26 22:41:29.408 DEBUG [pool-3-thread-1] CustomerTicketDAO.java:93 result >1, customerTicketId ----------->CustomerId_0, ticketId ------------>4

The other three thread dies at the line:

int result = query2.executeUpdate();

I don't understand what happens to the other three threads as I don't see anything in my log file.

Someone please help me here.

Thanks Raj

Answer 1

It's unclear (at least to me), exactly what error Sql Server and hibernate are returning in the case of the 3 failed tx's. But it's not surprising that they failed.

(Row) Locks are not queues, and nor are they filters. It's not surprising that the four select queries will return the same row because the presence of the lock does not change the data, and therefore also doesn't change the query results - it merely guards access to the data. I suspect, but do not know, that the lock might be bypassed here by hibernate caching the query.

The root problem is that you have four processes all contending for a single resource (the first unassigned ticket). While a properly implemented row locking scheme would work, it's a poor choice because it doesn't scale as well as the alternatives.

You'd be better off writing your dao with a synchronization block. This will handle the case where multiple threads in the appserver are contending for the resource at the same time. The simplest way would be to do this:

public synchronized void saveCustomerTicketUsingJDBC(String customerId) {
    Session session = getSession();
    ...
}

This handles the single appserver case nicely, although you need to be aware that there's no guarantee as to the order in which the threads are executed. I suspect, based on your variable names, that that might be a problem for you, but even if so, this solution doesn't make the problem any worse.

In the case where you have multiple appservers, then you can still have multiple processes contending for the same resource. Again, this could be solved with a (pessimistic) row lock, but I suspect you'd be better off with an optimistic locking solution. The optimistic lock would look something like this:

while (true) {
  session.getTransaction().begin();

  try {  
    Query query1 = session.createSQLQuery("select TOP 1 * from CustomerTicket where customerId is null");
    Object[] customerTicket = (Object[])query1.uniqueResult();

    Integer id = (Integer)customerTicket[0];
    ticketId = (String)customerTicket[1];
    logger.debug("Got ticket id -->"+ticketId);

    Query query2 = session.createSQLQuery("update CustomerTicket " +
                                            "set customerId = :customerId " +
                                            "where ticketId = :ticketId AND customerId is NULL");  
                                            // Notice the AND clause!!!
    query2.setParameter("customerId", customerId);
    query2.setParameter("ticketId", ticketId);
    logger.debug("QUery 2 executeUpdate : customerId : "+customerId+", ticketId :"+ticketId);
    int updateCount = query2.executeUpdate();
    logger.debug("updateCount >"+updateCount +", customerTicketId ----------->"+customerId+", ticketId ------------>"+ticketId);

    //  Did someone beat us to it? 
    if (updateCount == 0) {
        session.getTransaction().rollback();
        continue;
    }

    // Nope - we're winning so far, but the race isn't over yet...
    session.getTransaction().commit();
  } catch (OptimisticLockException ex) {
      logger.debug("Darn, someone DID beat us to it");
      session.getTransaction().rollback();
      continue;
  } catch (Exception ex) {
      ...
  }

  break;
}