ReSQL.ru
     
powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Асинхронное сохранение данных при связи ManyToMany
25 сообщений из 40, страница 1 из 2
  1  все
Асинхронное сохранение данных при связи 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
08.09.2021, 16:26
| Ответить | Цитировать | Написать  
Асинхронное сохранение данных при связи ManyToMany
    #40096055
Stanislav Bashkyrtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stanislav Bashkyrtsev
Гость
Ты хочешь сохранить книгу в одном потоке (и в одной транзакции), а тэги сохранить в другом потоке (и другой транзакции)? Ну особых проблем не вижу, только книгу нужно будет сначала закоммитить, иначе tx#2 не увидит ее.
...
Рейтинг: 0 / 0
08.09.2021, 16:32
| Ответить | Цитировать | Написать  
Асинхронное сохранение данных при связи ManyToMany
    #40096058
Музаффар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Музаффар
Участник
Stanislav Bashkyrtsev,

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

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


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

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

да делал бы так, но для увеличения скорости делал асинхронным, или сделать наоборот т.е. сделать основным не книгу а тегов? или вообще из ассоциативной таблицы сделать ещё один сущность...
...
Рейтинг: 0 / 0
08.09.2021, 17:31
| Ответить | Цитировать | Написать  
Асинхронное сохранение данных при связи ManyToMany
    #40096102
Stanislav Bashkyrtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Stanislav Bashkyrtsev
Гость
Музаффар
Stanislav Bashkyrtsev,

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

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

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

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

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

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

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

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

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

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

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

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

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


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

+

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

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

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

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

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

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

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

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

IMHO & AFAIK
...
Рейтинг: 0 / 0
10.09.2021, 09:26
| Ответить | Цитировать | Написать  
25 сообщений из 40, страница 1 из 2
  1  все
Форумы / Java [игнор отключен] [закрыт для гостей] / Асинхронное сохранение данных при связи ManyToMany
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=40096352&tid=2120353]:
 0ms
get settings:
 24ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 42ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 440ms
get tp. blocked users:
 2ms
others: 379ms
total:  915ms
созд. / загр.: 915ms
x
x
Закрыть


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