>>Примет нетти их отлично, в несколько потоков…
Получается 1 пакет может попасть в один поток, а второй пакет во второй поток. Следовательно на обработку они могут попасть «как повезет». Так?
Допустим они пришли в правильном порядке, но с задержкой в 1 мс. Как нетти отработает эти 2 запроса? В разных потоках или в одном? Собственно почему возник вопрос, потому что не понятно как нетти их отработает. Как она отрабатывает 20к запросов в сек?
Допустим я бью мечем, а противник ставит щит именно в такой последовательности. На Вашем сервере это может обработаться как — противник ставит щит и только потом я бью мечем? Зависит от того когда Ваш нетти отдаст пакет в логику?
Ну, например, возьмем простой случай — у Вас в приложении для новой сущности проставляется флаг DRAFT. А заказчик хочет изменить DRAFT на NEW (не только labels но и внутри кода).
Тогда делаем update и сбрасываем кеш.
По поводу iBatis — в EHCache такая же гибкая настройка с помощью регионов. Нужен кеш для статики — пожалуйста, нужен кеш для одного типа объектов — пожалуйста. Все гибко. Статика, кстати, у меня не сбрасывается.
Для сброса кеша есть решения, которые я описал в начале статьи, делается это за час максимум. Потом можно использовать во всех проектах.
По поводу удаления данных — в своих проектах я всегда использую флаг — deleted. Реально из базы не удаляю. Как раз для решения таких проблем как Вы описали.
NIO — это NEW IO. Я так понял Вы подразумеваете под NIO — Non-blocking IO.
Как бы там ни было, я по-моему понял в чем фишка Netty:
В случае NioServerSocketChannelFactory есть главный поток, который принимает входящие соединения. Когда появляется новое соединение, оно оборачивается в Channel и ссылка на Channel отдается дочерним потокам для обработки. Соответственно, при работе с Channel все команды ходят через главный поток. Так?
Да, в этом конкретном вопросе — это важно.
Вообщем если попытаться ответить баз маппинга, то должно быть приблизительно так —
если при session.load(User.class, 1L) делается выборка и User и SharedDoc (отдельными селектами или джоинами) то оба объекта будут в кеше. И во втором запросе значение будет доставаться из кеша.
Если так, то если на момент шага 3 мы имеем ту же сессию что и в случае 1, то данные будут не консистентны. Если же на шаге 3 у нас открывается новая сессия то все будет ок.
Получается 1 пакет может попасть в один поток, а второй пакет во второй поток. Следовательно на обработку они могут попасть «как повезет». Так?
update plan set status = 'new' where status = 'draft'
объекты в кеше при этом остались со значениями draft
Тогда делаем update и сбрасываем кеш.
По поводу удаления данных — в своих проектах я всегда использую флаг — deleted. Реально из базы не удаляю. Как раз для решения таких проблем как Вы описали.
Как бы там ни было, я по-моему понял в чем фишка Netty:
В случае NioServerSocketChannelFactory есть главный поток, который принимает входящие соединения. Когда появляется новое соединение, оно оборачивается в Channel и ссылка на Channel отдается дочерним потокам для обработки. Соответственно, при работе с Channel все команды ходят через главный поток. Так?
Вообщем если попытаться ответить баз маппинга, то должно быть приблизительно так —
если при session.load(User.class, 1L) делается выборка и User и SharedDoc (отдельными селектами или джоинами) то оба объекта будут в кеше. И во втором запросе значение будет доставаться из кеша.
По вопросу — я думаю зависит от того как будет выглядеть мапинг SharedDoc в классе User.