Очередь реквизитов для обновления данных на стороне клиента или сервера?

Question

Итак, у меня есть сетка с сортируемыми столбцами. При каждой сортировке происходит такое действие, как UpdataGridSorting, которое отправляет серверный запрос POST с новыми данными.

На сервере существует метод, который обновляет данные в базе данных. Он делает это довольно плохо: никаких блокировок для предотвращения одновременных обновлений данных в db, только блокировка для чтения при обновлении.

Поэтому у меня есть проблема: когда пользователь несколько раз нажимает на сортировку, отправляется несколько запросов, они могут перезаписывать данные одновременно и создавать грязные данные.

Таким образом, мое обходное решение заключается в очереди запросов на некоторой стороне и не обновлять базу данных до того, как предыдущее обновление будет завершено. С какой стороны лучше создать очередь?

Сейчас мое намерение:

saveGridColumnSorting = (dataToSend, action, forceSend) -> 
    if not forceSend 
     queue.enqueue(dataToSend.id); 
    if queue.lenght > 1 and not forceSend 
     return 
    $.ajax(
      url: url + "/" + action, 
      data: dataToSend, 
      success: (data) -> 
       if (queue.lenght > 0) 
        saveGridColumnSorting(queue.dequeue()); 
     ) 
    return 

Кроме того, если вы можете увидеть проблему XY, пожалуйста, обратитесь к шаблону или любому источнику, доверительному поможет исправить X в своем ответе.

Answer 1

Ну, схема с очередью на стороне клиента показала, что она работает в действии. Однако была найдена альтернатива: блокировать пользовательский интерфейс во времени, когда пользователь выполняет какое-либо действие. Не очень хороший опыт для сортировки столбцов, но все же более безопасный, чем запросы в очереди. Очередь на стороне сервера приведет к увеличению сложности, особенно для приложения MVC.

Answer 2

Особенно, если система предназначена для более чем одного пользователя (как вы сказали в комментариях), тогда на этой стороне есть очевидные риски. Во-первых, это уязвимость системы безопасности. Во-вторых, что происходит, когда вы получаете более одного пользователя, выдающего эти вызовы?

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

Существует также вопрос о том, что происходит, когда пользователь A запрашивает его сортировку в одну сторону, а затем, прежде чем база данных будет перечитана, пользователь B отправил свой собственный запрос сортировки, который уже был обработан. Не будет ли первый пользователь получить неправильный вывод, возможно, не осознав этого?

Чтобы избежать всех этих проблем — и при условии, что это возможно с точки зрения памяти, и другая информация, возможно, не предоставил — вы можете выбрать, чтобы сохранить кэшированные копии множества результатов, которые вы бы сортировать по-запросу, вместо изменения фактической базы данных. В качестве альтернативы, если механизм базы данных может выполнять сортировку по-прежнему только для чтения, то это то, что нужно использовать.