ads83

По определению, поле с аннотацией @Transient будет игнорироваться ORM. В обе стороны: и в БД ничего не запишется, и из базы его не установить.

Но можно воспользоваться доступом на уровне методов. Помимо аннотации @Column, надо поставить на геттере аннотацию @Access(AccessType.PROPERTY).
Так как поле - вычисляемое, довольно странно видеть setCrn(Double crn) в классе. Это может смутить ORM, да и людей тоже. Я бы пошел еще дальше и переименовал getCrn так, чтобы было понятно что это вычисляемое значение.

P.S. В современных БД есть такая вещь как (materialized) view - запрос или результат работы хранимки, к результатам которого можно обращаться как к таблице. Такой подход часто используется, у него есть определенные преимущества. Наверное, тут view будет избыточным решением, но для общего развития предлагаю посмотреть и в эту сторону.

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

// В Андроид контроллере
service.processAndroidLink(link)
// В iOS контроллере
service.processMacLink(link)

// в самом сервисе будут такие методы:
public void processAndroidLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = link;
  URL iosLink = createIosLink(link);
  URL webLink = createWebLink(link);
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
public void processWebLink(URL link) {
  // подготавливаем данные для записи
  URL androidLink = createAndroidLink(link);
  URL iosLink = createIosLink(link);
  URL webLink = link;
  var doc = prepareDocument(andriodLink, iosLink, webLink);
  save(doc);
}
private void save(document) {сохраняем в MongoDB}
}

Понятно, что вместо URL может быть любой другой тип.

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

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

Метод `peek` - это промежуточная операция. Одна из особенностей в том, что такие операции - ленивые, и у тебя нет гарантии когда они выполнятся и выполнятся ли вообще.

Подход с ExecutorPool более здоровый, но например в MarketplaceCollector я не увидел инициализацию `final ScheduledExecutorService executorService`.
Кроме того, если у тебя консольное приложение, то когда основной поток закончится, JVM пойдет завершать все дочерние и прибьет таску, которая запланирована через 3 минуты. Убедись, что оно живет достаточно долго.

Третий момент может быть в том, что сервис, к которому ты обращаешься, считает такое число запросов с таким интервалом избыточным и временно перестает отвечать. Это тоже требует проверки.