Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка ставки на аукционе. В DAO или в базе? / 6 сообщений из 6, страница 1 из 1
28.08.2014, 13:21
    #38731538
Recreate
Recreate
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
Доброго времени суток! Как лучше всего организовать добавление ставки на лот? Нужно проверить время, правильность ставки и т.д. Где лучше это делать? При инсерте в базу(триггер)? Или же в DAO сделать запрос, получить предыдущую ставку, сравнить с текущей и т.д. и потом инсерт? Мне лично кажется что в базе будет быстрее. Если ставка провалилась, то кидать эксепшн из базы, а в Java его обрабатывать. Какой вариант вообще имеет смысл?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.08.2014, 13:37
    #38731559
Petro123
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
Recreate,
быстрее на 0,000001 сек?
Как умеешь, так и пиши.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.08.2014, 13:42
    #38731575
Blazkowicz
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
Recreate,

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

На самом деле, достаточно просто для всех текущих аукционов держать очереди в памяти и разруливать их именно на Java. И лишь переодически персистить её снимки. Тогда можно избежать кучи SQL запросов. В highload системах, очень много оперативных данных живет в оперативной памяти. Соврешенно не обязательно на каждый пук юзера, останавливать весь процесс и ждать пока текущий шаг сохранится в базу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.08.2014, 14:45
    #38731678
mayton
mayton
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
RecreateГде лучше это делать? При инсерте в базу(триггер)?
На самом деле без доп. требований невозможно сформулировать основание лучшего или
худшего решения. Сколько звеньев в системе? Где что лежит? Как взаимодействует?
Где таймауты? Как быстро фиксация должна лечь в хранилище и многое прочее.

Тут в ПТ один чел говорил что триггеры в БД - это зло и их логику надо срочно переносить в Java.
Другой маргинал кодил свою собственную IMDB с "нулевым" отклкиком e.t.c. ИЧСХ даже тесты
приводил.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.09.2014, 19:34
    #38746060
Йуный джавистЪ
Йуный джавистЪ
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
авторНа самом деле, достаточно просто для всех текущих аукционов держать очереди в памяти и разруливать их именно на Java. И лишь переодически персистить её снимки. Тогда можно избежать кучи SQL запросов. В highload системах, очень много оперативных данных живет в оперативной памяти.

Если так делать, то после первого же бага в логике, приводящего к банальному NPE, данные окажутся в неконсистентном состоянии и уже не будет никакой возможности их восстановить. В случае использования СУБД, исключение будет отловлено и транзакция будет отменена.
Вообще, в general purpose языке трудно реализовать Software Transactional Memory. В clojure например реализовали, но там код выглядит так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
(defn run [nvecs nitems nthreads niters]
  (let [vec-refs (vec (map (comp ref vec)
                           (partition nitems (range (* nvecs nitems)))))
        swap #(let [v1 (rand-int nvecs)
                    v2 (rand-int nvecs)
                    i1 (rand-int nitems)
                    i2 (rand-int nitems)]
                (dosync
                 (let [temp (nth @(vec-refs v1) i1)]
                   (alter (vec-refs v1) assoc i1 (nth @(vec-refs v2) i2))
                   (alter (vec-refs v2) assoc i2 temp))))
        report #(do
                 (prn (map deref vec-refs))
                 (println "Distinct:"
                          (count (distinct (apply concat (map deref vec-refs))))))]
    (report)
    (dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)))))
    (report)))


Мне кажется, что PL/SQL проще.
авторСоврешенно не обязательно на каждый пук юзера, останавливать весь процесс и ждать пока текущий шаг сохранится в базу.
Если требуется durability, то в любом случае надо ждать запись на диск. Если durability не требуется, то можно использовать асинхронный коммит. В оракле можно вообще указывать на уровне отдельной транзакции, комитить ее синхронно или асинхронно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
13.09.2014, 21:53
    #38746114
scf
scf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проверка ставки на аукционе. В DAO или в базе?
В коде. Почему:
- проще написать, поддерживать и отлаживать
- будет хорошо работать при любой приличной нагрузке
- когда нагрузка станет неприличной, база тебя не спасет - нужно будет делать in-memory решение с хитрым персистом в базу (гугли LMAX architecture)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Java [игнор отключен] [закрыт для гостей] / Проверка ставки на аукционе. В DAO или в базе? / 6 сообщений из 6, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 435ms
Закрыть
start [/forum/topic.php?fid=59&tablet=1&tid=2126602]:
 0ms
get settings:
 7ms
get forum list:
 11ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 165ms
get topic data:
 7ms
get forum data:
 1ms
get page messages:
 26ms
get tp. blocked users:
 1ms
others: 213ms
total:  435ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]