Runtime данные в java

Нужно просто отправлять в базу, или еще и хранить локально на клиенте? Дальше из предположения, что только отправлять.

Почитай про producer-consumer java в гугле. Тебе нужна любая Queue.

Например, https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/TransferQueue....

Продюсер снимает GPS данные и кладет в очередь, консумер получает из очереди и отправляет на сервак апдейты.

Сама очередь заворачивается в какой-нибудь синглтон (прямо в коде или через спринговый бин).

я думал над чем-то похожим. в итоге все равно хранить в каком-либо runtime-объекте. даже не уверен что именно очередь нужна, хотя с ней будет скорее всего проще и логичнее.

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

Нужно просто отправлять в базу, или еще и хранить локально на клиенте?

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

консумер получает данные, и раскидывает: вначале в локальный кэш (гарантированное выполнение), потом долбится по сети пока не отправит

потом долбится по сети пока не отправит

дык а смысл ему долбиться если по сути пересылать нужно только конечный результат? собственно только в после этого сигнала ему в сеть и надо лезть.

локальный кэш - да, только вот вопрос как бы этот локальный кэш сделать? Т.е. данных не так чтоб совсем много, можно прямо в памяти хранить если что, в списке или еще как

или лучше сохранять каждый шаг, пофиг что трафик, а задержка исправляется консумером?

дык а смысл ему долбиться

ты это своему мобильному интернету объясни, какой ему смысл терять пакеты, отправленные в сторону сервера :)

можно прямо в памяти хранить если что, в списке или еще как

сам себе ответил) Если мапа - можно взять какой-нибудь key-value кэш, да хотя бы гуаву (как промежуточное решение между сложными бд и простым HashMap). Если список - просто ArrayList.

или лучше сохранять каждый шаг, пофиг что трафик, а задержка исправляется консумером?

ну ты можешь например, накапливать данные прямо в консумере

или если проц не одноядерный - накапливать в консумерАХ. Например, из очереди 4 консумероа забирают данные, но выплевывают в сеть только когда наполнятся целиком. Как их синхронизовать - какой-нибудь CyclicBarrier или CountdownLatch наверное (я на бегу пишу, сложно думать)

ты это своему мобильному интернету объясни, какой ему смысл терять пакеты, отправленные в сторону сервера

а, ты про клиента... я про сервер. тут тоже конечно можно что-то в таком духе устроить чтоб даже если база упала сервер продолжал долбить.

про мап/кэш - думаю мапа в целом хватит. любой трек имеет id, по ним разделить легко будет.

спасибо, буду решать

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

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

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

написанное выше строго имхо )))

Используй например такое https://github.com/jankotek/mapdb в отличии от обычного Map оно off-heap, так что если юзеров много джава будет меньше тупить. Можешь еще посмотреть на ChronicleMap, оно вроде тоже off-heap.

А ehCache оно совсем для другого, оно уничтожает данные (хотя наверное можно настроить и без уничтожения), но у них и off-heap вроде за денюжку.