|
Порядок обработки
|
||
|---|---|---|
Участник
Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщения: 39 476 |
||
| 24.09.2013, 12:01:03 |
|
|
|
|
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. Помогите, кто знает как решить задачу: Есть список пронумерованных бланков от 1 и до 10000. Есть менеджеры, которым выдаются эти бланки в определенном количестве: менеджер1 (М1) - 5 бланков, М2-3, М4-10 и т.д. В чем трудность. Выдача производится через несколько человек-операторов, которые оформляют выдачу. Как реализовать выдачу так, чтобы несколько операторов не оформили один и тот же бланк? Приложение реализовано на J2EE. Используется БД. У каждого бланка есть свой статус (свободный, выданный). Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 09:43:56 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
qi_ip, Вариант №1 Воспользоваться Транзакциями: распределением бланков и блокированием в процессе оформления бланков занимается СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 09:54:09 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Если устраивает оптимистическая блокировка, то можно воспользоваться встроенным механизмом @javax.persistence.Version ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 10:12:19 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Не видя кода ничего дельного сказать нельзя. Может быть вам помогут транзакции СУБД с определенными уровнями изоляции, может быть вам помогут джавовские синхронайзеры, может быть - CASы и коллекции из java.util.concurrent. Нужно больше конкретики, как у вас там это реализовано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 10:22:04 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
ivanraЕсли устраивает оптимистическая блокировка, то можно воспользоваться встроенным механизмом @javax.persistence.VersionОптимистичные блокировки тут как раз таки не подходят совершенно, так как в этом случае оператор, грубо говоря, сначала обработает документ, и лишь потом поймет, что сделал это зря. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 10:22:56 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
тут слабое звено это человеческий фактор и без построения правильных барьеров для операторов не обойтись: 1. оператор может начать работу по выдаче нового бланка только после совершения какого либо действия (например нажал кнопку получил номер бланка или возможность печати бланка). 2. оператор не может начать работу со следующим бланком без совершения какого либо действия (отмена выдачи предыдущего бланка или подтверждение выдачи). можно еще дать оператору возможность управлять состояниями выдачи бланков что ускорит процесс выдачи, но это грузит мозг оператора и увеличивает риски а дальше технические детали реакции системы на действия операторов например добавить бланку состояние (свободен, обрабатывается, выдан) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 10:40:29 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
cdtyjvivanraЕсли устраивает оптимистическая блокировка, то можно воспользоваться встроенным механизмом @javax.persistence.VersionОптимистичные блокировки тут как раз таки не подходят совершенно, так как в этом случае оператор, грубо говоря, сначала обработает документ, и лишь потом поймет, что сделал это зря. cdtyjv, оптимистическая блокировка решает поставленную задачу. авторКак реализовать выдачу так, чтобы несколько операторов не оформили один и тот же бланк?А вот какие там юзкейсы - ждем автора ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 11:17:06 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Можно просто распределять бланки операторам единственным выделеным потоком. Тогда никакой конкуренции не будет. А задача не такая уж нагруженая чтобы один поток не справился с парой сотен операторов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 11:20:50 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
ivanracdtyjv, оптимистическая блокировка решает поставленную задачу.У каждого инструмента есть своя область применения. Optimistic locking - это инструмент, который используется для долгоиграющих сценариев, когда мы не хотим блокировать изменяемый ресурс. Вы здесь видите такой сценарий? Я нет. Надо просто взять и атомарно изменить состояние нескольких записей так, что бы изменения из соседних транзакций их не перекрывали. Более того, у автора уже есть колонка состояния бланка, зачем туда громоздить еще и версию? Поэтому использование оптимистических блокировок здесь есть ни что иное, как придумывание велосипеда на ровном месте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 11:41:56 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
BlazkowiczМожно просто распределять бланки операторам единственным выделеным потоком. Тогда никакой конкуренции не будет. А задача не такая уж нагруженая чтобы один поток не справился с парой сотен операторов. +1 тем более, что распределение идёт через мышко-кликанье. А "мышки" вообще не требуют потоков, т.к. медленные события. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 12:01:03 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Petro123+1 тем более, что распределение идёт через мышко-кликанье. А "мышки" вообще не требуют потоков, т.к. медленные события. Единственный минус, что такую систему будет труднее поднять на кластере. Можно JEE Singleton попробовать. Он по-идее должен уметь быть кластерным синглтоном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 12:05:06 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Спасибо большое за ответы! Попробую реализовать согласно им! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 17:41:42 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
cdtyjvУ каждого инструмента есть своя область применения. Optimistic locking - это инструмент, который используется для долгоиграющих сценариев, когда мы не хотим блокировать изменяемый ресурс. Вы здесь видите такой сценарий? Я нет. Надо просто взять и атомарно изменить состояние нескольких записей так, что бы изменения из соседних транзакций их не перекрывали. Более того, у автора уже есть колонка состояния бланка, зачем туда громоздить еще и версию? Поэтому использование оптимистических блокировок здесь есть ни что иное, как придумывание велосипеда на ровном месте.cdtyjv, рекомендую уточнить область применения по книге J2EE Design Patterns , глава 10.2. Там, кстати, описаны плюсы и минусы некоторых предложенных здесь велосипедов. Что касается @javax.persistence.Version - я его порекомендовал за простоту, так как имеется уже готовый механизм, и нужно добавить только 1 поле и 1 аннотацию. А вот подойдет оно или нет - из условий задачи непонятно, поэтому и написал "если" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2013, 21:18:16 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
qi_ip, если бланки пронумерованы, то как разные операторы могут выдать один и тот же бланк? Они что, нумеруют их а процессе выдачи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2013, 01:09:04 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
BlazkowiczМожно JEE Singleton попробовать. Он по-идее должен уметь быть кластерным синглтоном. Не умеет (хотя у некоторых вендоров есть свои реализации). Единственный вменяемый механизм ручного контроля конкуррентности в кластере в EE -- JMS. Решение с пессимистичными блокировками в базе проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2013, 18:28:45 |
|
||
|
Порядок обработки
|
|||
|---|---|---|---|
|
#18+
Добрый день ! Я правильно понял задачу : Есть система массового обслуживания : Есть Менеджеры - их m - каждый за раз может взять x бланков. Есть операторы - их n - оператор смотрит какая емкость менеджера и выдает ему то количество которое в нем заявлено. так? Если так то объекты бланки это синхронизированный стек , из которого могут извлекать объекты (бланки) - операторы , если к ним пришел запрос от менеджера. тут нужно учитывать время которое тратит менеджер на обработку всех бланков, Время работы оператора по извлечению бланков и организацию стека бланков - либо это очередь к которой имеет доступ только один оператор , либо операторы могут обращаться к очереди одновременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2013, 13:45:42 |
|
||
|
|
start [/forum/topic.php?fid=59&fpage=208&tid=2128524]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
301ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
| others: | 278ms |
| total: | 702ms |
| 0 / 0 |
