гибкость и параллелизм данных - PullRequest
2 голосов
/ 21 декабря 2010

Я скоро приступлю к проекту среднего масштаба. Хотя это не очень высокий приоритет в моем большом списке дел, но я пытался как-то эффективно справиться с параллелизмом данных. Я буду использовать EJB-компонент без сохранения состояния для моего приложения Flex.

В идеале я ищу простой способ борьбы с параллелизмом данных. например если данные сохраняются в одном интерфейсе, они обновляются в другом. Или предупреждает, что данные были изменены перед сохранением новой версии данных.

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

Ответы [ 2 ]

1 голос
/ 24 декабря 2010

Если вы планируете использовать каналы AMF для связи, вы можете использовать функцию длинного опроса, чтобы эффективно поддерживать в приложении тип «push-сообщения».И службы данных BlazeDS и / или GraniteDS поддерживают эту возможность именно по указанным вами причинам.

0 голосов
/ 21 декабря 2010

Системы контроля версий хранят user_id и datetime для каждой ревизии. Вы можете использовать тот же метод. Клиентское приложение получает текущую дату и время для запрошенных данных и сохраняет их. Приложение отправляет измененные данные с сохранением даты и времени. Сервер проверяет дату и время последней ревизии и полученную дату и время. И ответьте на приложение соответственно.

Второй метод - использование широковещательных сообщений от сервера к клиентам. Но я не думаю, что это применимо в вашем случае. Этот метод обычно применяется в локальной сети (среда со стабильным подключением).

...