Это вопрос проектирования архитектуры приложения и поэтому религиозный вопрос. Задайте вопрос себе - кому и как вы будете отдавать сообщения об ошибках и как их обрабатывать (продолжать, перезапускать, уничтожать что-то т.п., на что влияет данная ошибка)? В зависимости от этого будете выбирать место для throw и catch.
Насколько часто, не знаю, статистику можно поискать в И-нете. Время тратить стоит, чтобы научится пользоваться менеджерами очередей и понять, когда и зачем они применяются. Если не JMS, то RabbitMQ или MSMQ, или MQSeries, или еще чего.
Ну вот вы варите суп, нужно все приправы положить чтобы он получился? Язык Java требует явного указания откуда дровишки, вы можете не использовать import, а писать полное наименование классов и объектов из них. И ЕГ здесь ни причем.
Первая заповедь программиста - не изобретать велосипед. Для управления очередями существует куча готовых реализаций. Например https://www.rabbitmq.com/tutorials/tutorial-one-ja... А здесь обо всех более-менее значимых проектах менеджеров очередей queues.io
Используйте один из серверов приложений, для начала tomcat например. Для него есть поддержка в разных IDE. Или glassfish, но это будет малость посложней.
Не указали на чем сервер. Однако если дома работало, а на хостинге нет, то нет mysql драйверов. Либо положите его в нужное для вашего сервера место, либо укажате в настройках где оно лежит.
Все просто
Если есть две зависимые таблицы, то при выборке из одной из них
при eager будут подтянуты данные из выбираемой таблицы и из зависимой
при lazy зависимая таблица будет подтянута только когда к ней действительно будет обращение в коде
Eclipse, Netbeans и т.д., запускается на серверах приложений - Glassfish, Tomcat и пр.
Читать можно много и долго, сузь область backend-backend-у рознь.
Поиграй со стандартными примерами Netbeans, я с них начинал.
Вручную написать коннектор и описать все объекты используемые при обмене - все то, что генерируется по WSDL-автоматически. Риторический вопрос - а зачем придумывать себе гемморой?