слишком частая запись, тайм-аут для хранилища данных - PullRequest
2 голосов
/ 09 февраля 2010

Я читаю вики-движок приложений, если в сети слишком часто пишут более 5 раз за 1 секунду. В вики введено использование "осколок" подход "как обходной путь. Могу ли я знать, если мы используем весну @transactional на этом, это может предотвратить истечение времени ожидания конкуренции хранилища данных, так как запись выполняется одновременно?

Ответы [ 2 ]

1 голос
/ 16 февраля 2010

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

1 голос
/ 13 февраля 2010

Нет, вы не можете этого сделать. Независимо от того, используете ли вы @transactional, это не решит проблему - тот факт, что у вас есть один объект, к которому вам нужно продолжать писать. Предел конкуренции будет оставаться тем же, какой вы используете.

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

С другой стороны, если вам не требуется слишком большая точность, вы можете очень часто пытаться писать в memcache. Пределы конфликтов записи намного выше при записи в memcache или приращении счетчика там. Затем вы можете записать и сбросить счетчик через заданный интервал.

...