Code: Select all
doThat(request, response);Code: Select all
acceptRequest(request);
processResponse(response);
Какие как, некоторые поддерживают ))Palych wrote:Хорошо, допустим сделали мы асинхронный сервер приложений.
А как там дела с асинхронными клиентами к базам данных?
Поддерживают ли сами базы асинхронное общение с клиентами?
(имеется в виду обычные запросы, не такие вещи как отслеживание изменений таблиц и проч.)
Только при этом, если база данных не поддерживает асинхронные операции (всякие async commit и т.п.) с соответствующим асинхронным коннектором (драйвером), то все это просто будет исполнятся в отдельном потоке. Чудес не бывает.helg wrote:В Spring есть Reactor - совершенно стандартный метод сделать что угодно асинхронным образом. В нём что http, что база, что сервер следующего уровня - всё исполняется без проблем.
Это верно: тут как говорится: "одно неосторожное движение - и ты отец".Интеррапт wrote:Только при этом, если база данных не поддерживает асинхронные операции (всякие async commit и т.п.) с соответствующим асинхронным коннектором (драйвером), то все это просто будет исполнятся в отдельном потоке. Чудес не бывает.helg wrote:В Spring есть Reactor - совершенно стандартный метод сделать что угодно асинхронным образом. В нём что http, что база, что сервер следующего уровня - всё исполняется без проблем.
Ну так многие базы данных таки поддерживают асинхронные операции. Тот-же PostgreSQL. Ну или MongoDB. Да много кто. Могут быть свои минусы, например для PostgreSQL в случае сбоя при async commit может произойти потеря данных (но не порча данных, т.е. база восстановится в работоспособном состоянии), но в большинстве случаев это не является проблемой. Еще ес-но нужно, чтобы драйвер / коннектор был под нужную платформу.Palych wrote:Это верно: тут как говорится: "одно неосторожное движение - и ты отец".
И ведь не просто поток выделится. Практически все удалённые сервисы будут иметь такой параметр как timeout. А это - ещё один поток...
Поэтому я и говорил о "чистоте расы"...
Это особенность реализации асинхронных операций конкретно в PostgreSQL или вообще?Интеррапт wrote: Могут быть свои минусы, например для PostgreSQL в случае сбоя при async commit может произойти потеря данных (но не порча данных, т.е. база восстановится в работоспособном состоянии).
Palych wrote:Спасибо, отцы!
Palych wrote:тут как говорится: "одно неосторожное движение - и ты отец".
АццкоМото wrote:Palych wrote:Спасибо, отцы!Palych wrote:тут как говорится: "одно неосторожное движение - и ты отец".
Если там вам везде нужна аснихронность, то чего вы queue каких нибудь не насуетеPalych wrote:(Поднимаю старый топик)
В копилку асинхронных инструментов: Reactive Extensions
Сам не использовал, но прослушал лекцию на ACM - впечатлился. "Это такая брат лекция! Один раз послушаешь - и на всю жизнь!" (c)
К сожалению запись лекции еще не выложили, а главная мысль - Observables as Iterators и применение множественных операций к ним в описании отражена слабо...
?Code: Select all
try {
doThis();
if (itIs()) {
doThat();
} else {
doSomethingElse();
}
} catch(error) {
handleError(error);
} finally {
finishThat();
}
Палыч, я подобное нарисовал на коленке для Qt-шного C++ проекта. Довольно просто, а адаптировать на разные платформы штуки вроде MS Parallel Patterns Library желания не было.Palych wrote:Нарисовать очереди можно, но хотелось бы иметь абстракцию для асинхронных вычислений приближенную к традиционным вычислениям:Чтобы не пришлось рисовать кучу переменных и хитрым образом изменять их значение только для того чтобы обеспечить выполнение алгоритма...Code: Select all
try { doThis(); if (itIs()) { doThat(); } else { doSomethingElse(); } } catch(error) { handleError(error); } finally { finishThat(); }
Примерно для этого и есть монада. Например в скале с монадой Future это бы выглядело примерно такPalych wrote:Нарисовать очереди можно, но хотелось бы иметь абстракцию для асинхронных вычислений приближенную к традиционным вычислениям:Чтобы не пришлось рисовать кучу переменных и хитрым образом изменять их значение только для того чтобы обеспечить выполнение алгоритма...Code: Select all
try { doThis(); if (itIs()) { doThat(); } else { doSomethingElse(); } } catch(error) { handleError(error); } finally { finishThat(); }
Code: Select all
for {
doneThis <- doThis()
doneThat <- if itIs() doThat() else doSomehtingElse()
} yield finishThat() onError {
case error: Thowable => handleError()
}
Вы даже не представляете как и нам это надоreality wrote:Для скалы есть еще клевый async который позволяет в императивном стиле писать non-blocking код: https://github.com/scala/async
В JS для этого promises, и насколько я понимаю видео то что надо
Кстати, вот та лекция, правда в другом варианте: http://youtu.be/XE692Clb5LUPalych wrote:(Поднимаю старый топик)
В копилку асинхронных инструментов: Reactive Extensions
Сам не использовал, но прослушал лекцию на ACM - впечатлился. "Это такая брат лекция! Один раз послушаешь - и на всю жизнь!" (c)
К сожалению запись лекции еще не выложили, а главная мысль - Observables as Iterators и применение множественных операций к ним в описании отражена слабо...