powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / Асинхронное сохранение данных при связи ManyToMany
40 сообщений из 40, показаны все 2 страниц
Асинхронное сохранение данных при связи ManyToMany
    #40096053
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте, собственно сабж
что делаю:

сущность Tag
Код: java
1.
2.
@ManyToMany(mappedBy = "tags")
    private List<Book> books = new ArrayList<>();



сущность Book
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
@ManyToMany(cascade = {
            CascadeType.PERSIST,
            CascadeType.MERGE
    })
    @JoinTable(name = "book_tag",
            joinColumns = @JoinColumn(name = "book_id"),
            inverseJoinColumns = @JoinColumn(name = "tag_id")
    )
    private List<Tag> tags = new ArrayList<>();

    public Book(String title){
        this.title=title;
    }

    public void addTag(Tag tag) {
        tags.add(tag);
        tag.getBooks().add(this);
    }




будет естественно работать вот так:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Book book1=new Book("книга1");
        Book book2=new Book("книга2");

        Tag tag1=new Tag("тег1");
        Tag tag2=new Tag("тег2");
        Tag tag3=new Tag("тег3");

        book1.addTag(тег1);
        book1.addTag(тег2);

        book2.addTag(тег3);

        bookRepository.saveAll(List.of(book1, book2));



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

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

З.Ы. возможно книги и теги не совсем удачный пример, но с юзером и адресом будет правильнее наверно, но суть не меняется )...
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096055
Ты хочешь сохранить книгу в одном потоке (и в одной транзакции), а тэги сохранить в другом потоке (и другой транзакции)? Ну особых проблем не вижу, только книгу нужно будет сначала закоммитить, иначе tx#2 не увидит ее.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096058
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал?
если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096076
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар
Stanislav Bashkyrtsev,

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


Делай синхронно. :-)

Можно конечно покапать в сторону чего-нибудь реактивного/корутинного.
Но это сложнее. :-)
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096092
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgul,

да делал бы так, но для увеличения скорости делал асинхронным, или сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность...
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096102
Музаффар
Stanislav Bashkyrtsev,

в том то и дело что так нельзя т.к. тэг сохраняется с помощью книг... а когда двух потоках то в другом потоке тоже надо будет сохранить именно книгу а не тег... или что то я не правильно сказал?
если сохранить просто тег то в промежуточной таблице не будет связи между книгой и тегом
Если связь сохраняется со стороны книг, то в async методе можно просто достать только что сохранившуюся книгу из БД (а можно и не доставать, но делать merge()) и добавить этой новой книге тэгов.
Музаффарили сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность...Можно и так.

PS: Я не видел еще подобных ситуаций, чтоб сохранение сущностей было такое медленное, чтоб нужно было в async выносить..
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096110
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AFAIK
кроме синхронности/ассинхронности, есть еще такая вещь, как колличество коммитов на единицу записываемых данных )))

т.ч. можно сделать все ассинхронным, но скорость будет на порядки (десятки-сотни) раз медленней, чем синхронно но в одной транзакции. А если в одной транзакции еще и массово писать (например команда COPY), то смысла в ассинхронности записи в БД вообще может не быть, т.к. один клиент вполне будет способен сервер и диск сервера загрузить по самое нехочу (даже при хорошем сервере и хорошем серверном диске, сотню мегобайт с клиента чисто данных... не каждый сервер выдержит).
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096142
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096163
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
Очень странное ТЗ.
- можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ
- можно собирать во временной таблице в бд.
Тебе как лучше?)))
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096164
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
СУБД не мусорка чтобы писать туда что попало. Например одну руку от человека. Или один палец.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096192
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PetroNotC Sharp
Музаффар,
Очень странное ТЗ.
- можно собирать коллекцию в оперативке ПОКА ВСЕ ДАННЫЕ НЕ ПРИДУТ
- можно собирать во временной таблице в бд.
Тебе как лучше?)))

1. Согласен но это не даст мне то что надо, т.к. время ожидания останется прежним.
2. Это что даст?

- знаю что СУБД не мусорка но к чему это?

У меня сбор данных происходит из разных источников следовательно время на это уходит по разному чтоб уменьшить это мне нужно как то параллелить обработку данных, т.е. в момент ввода названии книги из одного источника придёт инфо об этой книги и там же из другого источника теги по этой книги. При этом пользователь не должен ждать сбора данных по тегам и их записи в бд
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096259
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
Тебе нужно делать так как учат в ВУЗАХ,
ПЕРВЫЙ ЭТАП это создание модели и выделение сущностей.
Если в твоей ИС "Б" сущность книга, то пол книги это промежуточный этап и ненужно полкниги писать в субд. Нужно складировать в сессию и собирать всю книгу.
Если наборот, в твоей "Б" важны "источники книги" то сущность уже не книга а куски книги с меткой источника.
ID_ИСТОЧНИКА NAME DATETIME

>При этом пользователь не должен ждать сбора данных по тегам и их записи в бд
≠Он в любом случае не ждет. Запись в бд занимает милли и макро секунды. А ответ сервиса" А" занимает минуту.
Юзверь ждет сервис А а не твой сервис Б.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096263
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
Пора переходить к логам по времени и дать в топике цифры нагрузочных тестов.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096324
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
БД не запрещает асинхронность и мультипоточку. Но в БД есть констрейнты которые определяют
целостность объектов. И было-бы лучше чтобы эти констрейнты были максимально
строгими по отношению в записываемому объекту.

В противном случае у нас в БД будет мусор. Тоесть какие-то огрызки книг тегов и непонятно где
логический конец.

Возможно имеет смысл просто накапливать в памяти модель сложного объекта и записывать его
когда он будет полностью сформирован.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096352
mayton , если мы получаем неполные данные и могли бы их уже показать пользователю не заставляя его ждать еще минуту, то тут других вариантов то и нет. И мы БД должны подстроить под наши требования, а не под высокие (но не достижимые) идеалы.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096359
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя
с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД? Тем более что Музафар
пишет что с некоторых сервисов данные приходистя ждать более минуты.

Запишете в БД когда будет готов весь бизнес-объект.

У вас же не возникает желания сохранять в базу формочку строка-за-строкой в той скорости как оператор
из набирает. Верно?
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096381
mayton
Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя
с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД?
Дак эти данные пользователю возможно не просто для "посмотреть", он может их начнет редактировать уже, сохранять изменения в БД. А доп инфа дойдет и будет доступна позже.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096391
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пускай автор скажет. Получается что мы тут сильно додумываем бизнес-сценарии.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096462
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

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

"Hibernate наше все" ( TM ) - т.ч. хождение по граблям может продолжатся долго. Наша песня хороша, начинай с начала.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096540
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev
mayton
Тут жеж речь не об этом. Конечно отображайте пользователю данные сразу. Один виджет - тянет сведентя
с одного датасорса. Второй с другого. И т.д. Всё асинхронно. Но тогда при чем здесь БД?
Дак эти данные пользователю возможно не просто для "посмотреть", он может их начнет редактировать уже, сохранять изменения в БД. А доп инфа дойдет и будет доступна позже.
не додумывайте за автора что является доп инфой а что нет.
Это чисто вопрос ТС
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096555
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар
отвечу на вопрос зачем синхронность вообще: дело в том что данные берутся из удаленных сервисов, и если они загружены то ответ приходит чуть дольше иногда доходит до минуты... и когда все в одном потоке то придется ждать условно 1+ минут чтоб данные пришли и записались в бд


ИМХО стоит посмотреть в сторону чего-то типа RxJava .
Для того чтобы "собирать" сущность.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096602
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

+

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

в целом попробую конкретизировать задачу:
есть таблицы/сущности: Юзер (где логин пароль и т.д.), Документ (где биометрические данные, фио, дата рождения и т.д.), адрес (ну и так понятно только тут как постоянный адрес так и временный) и другие таблицы.

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

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

и так кейс №1
сделаем в одном потоке: все круто все замечательно но есть одна проблема, время регистрации займет от 1.5 секунды до 1+минут (это изза того какой то сервис скажем адрес заставил ждать) и к тому же если это все происходит в одной транзакции возможен откат т.к. какой то удаленный сервис дал исключение... возможно? скорее да.

кейс №2
попробовать параллелить сбор данных, получив входных данных идем по документу получив документ идем по другим удаленным сервисам только уже этих сервисов вызываем асинхронно тогда у нас сбор данных будет прозрачным отдельно от основного потока, таким образом мы будем ждать только одного сервиса (основного) для Документа...

надеюсь смог объяснить суть.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096606
Музаффар , я такие проблемы решал след образом:
1. Сохраняем небольшой кусок данных который позволяет пользователю хоть сколько-то работать в системе. Коммит.
2. Тригерим жобу которая смотрит в БД и для всех у кого данные не проставлены - запрашивает эти данные. Если делать иначе, то есть риск что что-то в сервисе сломается (ну или просто наш сервер кто-то перезагрузит) и данные никогда не попадут в БД. А нам нужен механизм который попробует еще, а значит лучше ориентироваться на БД. Такая жоба может не только по требованию запускаться, но и по шедулеру. Хотя при насильном запуске можно все-таки явно указать про какие записи речь, иначе жоба может начать слать запросы для пользователей в другом порядке, а значит наш последний пользователь прождет не минуту, а 5.
3. В это время пользователь может таки успеть дойти до тех мест где эти данные требуются. Если такое произошло, то показываем пользователю спиннер, мол, "мы запрашиваем данные, жди". Как только данные пришли - спинер прячем, показываем то ради чего он сюда пришел.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096612
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тут вопрос лежит в бизнес плоскости а не в технической. На что готов пойти бизнес чтобы дать пользователю начать работать с системой до полного сбора информации.
Если очень надо, то да - создание временной записи и асинхронная джоба со всеми сопутствующими(обработка ошибок, откат транзакции, замена временной записи на постоянную). Судя по тому что тс задаёт такие вопросы он явно не искушен, так что вряд-ли представляет гемор вносимый асинхронностью в данном кейсе...
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096620
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гемора не вижу. Но не понимаю, если данные хранятся в другой системе, зачем их тащить в основную?

1. Данные необходимы для авторизации. Попаболь не понятна, пока данные не собраны, корректно авторизовать в системе мы не можем. Пусть ждет или "система недоступна по техническим причинам".
2. Если таблицы в основной система эта кэш и данные при логине подкачиваются для "прогрева кэша". Тогда опять таки, кэш должен работать как кэш. Данные есть и более-менее актуальны - возвращаем из кэша, данных нет - запрашиваем в медленном хранилище, помещаем в кэш, возвращаем.
Прогрев кэша: асинхронно (скорее всего в Java), дергаем get'еры которые данные из кэша возвращают и на результат просто забиваем нано-болт. Подкачка и сохранение данных, задача модуля реализующего кэширование, а никак не модуля авторизации
3. Данные нужны чисто для логирования. НО, логирование это необходимая часть процесса авторизации, т.ч. смотри п.1. Будут разборки службы безопасности, а логи пустые, фэкап.

IMHO & AFAIK
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096621
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev

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


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

Разумеется, откуда приходят данные мы не знаем, но с учетом "долгое время" можно предположить что это или сторонняя организация или вообще какая-то шина, типа СМЭВ (система межведомственного взаимодействия) или прочие личные кабинеты, контактики, линкедиды.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096623
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что мне не понятно, откуда тут взялись проблемы с мани-то-мани.

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

Ну и по времени операций, конфликта не видно:

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

При чем тут мани-то-мани, нифига не понятно.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096624
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар
надеюсь смог объяснить суть.
нет.
Описание юзкйса не начинается "сделаем в одном потоке".
))))
Юзкейс описыает ДЕЙСТВИЯ ПОЛЬЗОВАТЕЛЯ.
НАПРИМЕР
1.юзверь ввел sql.ru
1.1 не зарегестрирован
1.1.1 вводит инфо в форму регистрации.
....
??
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096627
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если юзкейс выше верный, то мы получаем два потока. Основной и фоновый для юзверя.
Основной это минимум данных (форма регистрации)
Фоновым можно назвать что угодно в вашей системе.
ИТОГО - В ЧЕМ ПРОБЛЕМА?
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096628
Leonid Kudryavtsev
Stanislav Bashkyrtsev

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


Мне кажется, что если показывать "мы запрашиваем данные, жди", то и действительно в этот момент и выполнять сам запрос данных. Т.к. можно получить вменяемую ошибку от стороннего сервиса, показать ее пользователю и уже с этой вменяемой ошибкой он обратиться в техподдержку. Не нужно будет раскапывать логи, пытаться по метки времени находить ошибки и так далее и тому подобное. Мало того, возможно и сразу отправить в тех. поддержку стороннего сервиса, т.е. уменьшить работу своих коллег. А возможно ошибка от стороннего сервиса вообще будет звучать так "вы запретили доступ к своим персональным данным, поэтому они не предоставлены" - т.ч. возможно, даже сам пользователь эту ошибку и сможет устранить.
Зависит от цели - если хочется чтоб к тебе не обращались лишний раз, то да - запрос можно выполнить когда пользователь пришел. Если же задача - создать удобный продукт, которым будет приятно пользоваться, то прийдется постараться.

И если встает вопрос про ошибки, то их прийдется записывать прям в БД чтоб потом показать пользователю когда он дойдет до той страницы. Ну или асинхронность можно сделать со стороны UI (фоновый AJAX запрос на получение этих данных), в случае SPA мы можем показать ошибку как только она возникла, даже находясь на другой "странице". Тоже рабочий вариант в некоторых ситуациях.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096688
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Stanislav Bashkyrtsev,

Не очень понял описываемое Вами. Думаю в целом мы об одном и том же, просто в разной терминологии )))

Да, делать можно по разному.

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

Вариант cache - универсальный. Первый вариант - заклепотный велосипед. Завтра выяснится, что данные в сторонней системе могут меняться после логина и что? для обновления "баланса по счету" после онлайн платежа обязательно перелогинтесь? Заклепка.

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

IMHO
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096692
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В данном топике - плохое ТЗ. Или недостаточно проработанное. Непонятно является ли обязательным наличие
в объекте пользователя опциональных данных которые подтягиваются из сторонних систем.

Кроме того автор всех запутал вводя какие-то книги и прочее.

Тут в задаче нет технической проблемы вообще. Callable/Future. Retry-logic если не получили результат.

Тут есть проблема недостаточной ясности что делать в тех и других ситуациях. Что делать если внешний сервис
не ответил через час? Что делать если он в течение дня не ответил?
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096719
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton,

+1
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096754
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton, согласен на счет книг и тегов и изза этого привел более реальный пример
кстати структуру бд менял... (на картинке можно посмотреть)
тут самым важным является сервис по получении бирметрических данных это у меня паспорт и биометрические_данные
а почти всех остальных таблиц можно в разных потоках
таким образом юзверь ждет только прихода данных из главного источника для заполнения биометрических данных а другие таблицы асинхронно заполняются а вот если по какой либо причине кто то из них откажет то сбрасывается исключение и записи не будет, а при входе в систему можно будет ещё раз запросить если нет данных в других таблицах, в том числе адрес


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

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
    @Override
    @Transactional
    @Async
    public void getAddressFromRemoteServiceAndSaveData(User user) {
        log.info("Method getAddressFromRemoteServiceAndSaveData");
        try {

            AddressInfoDto citizenAddress = externalServices.getCitizenInfoServiceNewWithRestTemplete(user.getPin());
            if (citizenAddress != null) {

                PermanentRegistration permanentRegistration = citizenAddress.getPermanentRegistration();

                Address pAddress = addressMapper.fromPermanentRegistration(permanentRegistration);

                Address savedAddr = addressRepository.save(pAddress);

                userAddressRepository.save(userAddressMapper.toUserPAddressFromObjs(permanentRegistration, user, savedAddr));

                log.info("Permanent Address data for new user by pin {}, is saved and data is: {}", user.getPin(), pAddress);

                if (!citizenAddress.getTemporaryRegistrations().isEmpty()) {
                    List<TemporaryRegistration> temporaryRegistrations = citizenAddress.getTemporaryRegistrations();

                    temporaryRegistrations.forEach(tr -> {
                        Optional<Address> addressByCadastreAndAddressType = addressRepository.findByCadastreAndAddressType(tr.getCadastre(), AddressType.TEMPORARY);
                        Address savedTempAddr;
                        if (addressByCadastreAndAddressType.isEmpty())
                            savedTempAddr = addressRepository.save(addressMapper.fromTemporaryRegistration(tr));
                        else
                            savedTempAddr = addressByCadastreAndAddressType.get();
                        userAddressRepository.save(userAddressMapper.toUserTAddressFromObjs(tr, user, savedTempAddr));
                        log.info("Temporary Address data for new user by pin {}, is saved and data is: {}", user.getPin(), tr);
                    });
                }
            } else {
                log.warn("The remote service ADDRESS is not responding and we cannot write data for the user by pin is: {}", user.getPin());
            }
        } catch (Exception e) {
            log.warn("Exception in Address service, pin is: {} and exception message:{}", user.getPin(), e.getMessage());
        }
    }
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096767
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096799
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
Я понял что ты читаешь только последний пост. Остальные нет.
- биометрические данные обязательны а остальные нет? Тогда причем райзе на необязательные? Он же их НЕ ЖДЕТ!
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096800
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если "записи не будет" относится к доп данным, то фиг с ними. Это не обязательные данные.
Тогда в чем вопрос то.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096803
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
getAddressFromRemoteServiceAndSaveData это не обязательные данные для входа?
Тогда почему не повесить их на JOB/шедулер?
ГОСУСЛУГИ смотрели? Там запрос в ГАИ на оплату штрафа. И юзверь может кроме шедулера самого сайта раз в сутки инициировать проверку кнопкой немедленно.
Всё работает и все довольны.
Работает AJAX и никакой асинхронности.
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096804
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Музаффар,
Ты AJAX из коробки заменил кучей кода и головной болью админа сервера и девочек техподдержки
...
Рейтинг: 0 / 0
Асинхронное сохранение данных при связи ManyToMany
    #40096805
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я думаю что запросы в думу, кадастровую палату, наркологический диспансер,....
не надо инициировать из ГУИ миллиона юзверей.
Надо делать заявки и отвязать эти процессы от ГУИ.
...
Рейтинг: 0 / 0
40 сообщений из 40, показаны все 2 страниц
Форумы / Java [игнор отключен] [закрыт для гостей] / Асинхронное сохранение данных при связи ManyToMany
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]