Call service management in the cache

Prior to the end of the call service management, is to maintain the call service, including the increase in the type of call service or modify the call service type. Today, assigned to a new task, is to do the customer's order of the call service type, which is the type of call service is taken out of the database, and then click on the call service, will certainly send a service request to the corresponding responsible waiter, This request is temporary. Obviously it is not necessary to create a new table in the database, so the cache is used, that is, the call service is put into the cache, and the service displayed by the waiter is taken out of the cache. See cache do not feel very scary, start is to put the data into memory, define a map can, before the old version of the dining item is defined a CONCURRENTMAP, which is stored in the table number and Callcache, Baidu a bit this map is hashmap improvement, Resolves a thread insecurity issue in which Callcache has the name of the service, the time the service was issued, the status being processed, the response time of the service, and the response of the attendant. Waiter to root in their own responsible table number to get to all the table call service, because the customer has not finished, the page has not yet out, so personal feeling or wait and see the waiter to make what to do again.

         time has passed a lot of days, today, and then summed up the problem of the module itself and the solution, the previous call service pair is corresponding to a table number, The definition of map can only save the next call service, I think of a thought not very reasonable, so the map redefined, defined as a table number corresponding to a Tablecallcache,tablecallcache object has a List<callcache >,list inside the object is a single call service, it is reasonable to feel such a thing. Also consider the waiter response process, feel the same request, if the waiter does not accept the customer can not send the same service again, if accepted, two times the same request can not be less than 1 minutes interval. Because the waiter can operate the table in a state, that is, to close the table and so on, so not all the table can send the request, only the table in the available state can send the request. Looked at the waiter written by the waitress for the operation of the table, found that the attendant controller inherits the class and I wrote the controller inherits the class is different, so that things put in the cache can not be taken, so I went to write my controller inherits the class changed to the waiter-side inheritance class, and not yet tested Oh, I don't know if it's good or bad.