• Как JPA понимает, какую реализацию использовать?

    shebbs
    @shebbs Автор вопроса
    В общем ответ такой:
    JPA - это не просто какая-то абстрактная спецификация, там есть вполне конкретные классы, выполняющие конкретные действия. В частности:
    import javax.persistence.Persistence;
    EntityManagerFactory factory = Persistence.createEntityManagerFactory("dvdPU");

    В классе Persistence метод createEntityManagerFactory выполняет вполне конкретные действия (можно посмотреть исходники тут https://github.com/javaee/jpa-spec/blob/master/jav...), а именно:
    1. Сначала находит в classpath все возможные классы, которые могут создать EntityManagerFactory.
    2. Потом перебирает все, которые нашел, по очереди, каждый раз передавая очередному "создателю" конфиг из persistence.xml.
    3. Как только "создатель" создает фабрику, цикл прекращается и фабрика возвращается в нашу программу.

    Если мы не указываем в persistence.xml через тег provider конкретного провайдера, тогда фабрику нам создаст первый попавшийся провайдер. Если же указываем, тогда фабрику нам создаст именно тот, который мы хотим. Пусть Persistence нашел в classpath два провайдера в таком порядке: EclipseLink и Hibernate. Он сперва просит EclipseLink создать фабрику и передает ему конфиг. EclipseLink видит, что в конфиге написано "Hibernate" и отвечает: "Извини, братишка, не в этот раз, в конфиге написано, что это хибер должен делать. Так что я не буду". Тогда Persistence идет дальше по списку, просит хибер и передает ему конфиг. Хибер видит, что в provider стоит org.hibernate.jpa.HibernatePersistenceProvider и создает фабрику.

    Вот так у нас и оказывается КОНКРЕТНАЯ, хиберовская, реализация фабрики, из которой мы уже дальше получаем такие же конкретные, хиберовские, реализации EntityManager и прочее.

    Ну а в classpath все эти провайдеры попадают за счет того, что у нас в pom есть зависимости.
    Ответ написан
    Комментировать
  • Число одновременных соединений сервера?

    Соединение характеризуется двумя сокетами. А вот сам сокет характеризуется не двумя параметрами (ip + порт), а пятью:
    ip + порт локальные
    ip + порт того, кто присоединился
    протокол

    Пусть у нас серверная программа на компьютере с ip 192.168.0.10 слушает порт 54123.
    Пусть к ней присоединяются два клиента, их ip и порт на ИХ компьютерах такие:
    192.168.100.1, порт 64001
    192.168.200.5, порт 62038

    Тогда на сервере при образовании соединения ОС создает два сокета, каждый из которых идентифицируется вот так:
    ___server local ip + port___client remote ip + port___protocol
    1) 192.168.0.10:54123____192.168.100.1:64001_____tcp
    2) 192.168.0.10:54123____192.168.200.5:62038_____tcp

    Таким образом, серверной программе с точки зрения "растраты портов" не важно, сколько народа к ней присоединяются, т.к. "своя" пара ip + порт у нее всегда одинаковая => разговор о 64k портов в данном случае не актуален.

    Об ограничении в 65k портов можно говорить в случае если бы мы хотели запустить 65k серверных программ и каждой тогда понадобился бы свой порт для прослушивания. Но столько программ очень вряд ли кто-то запускает и к тому же две программы могут "разделять" один и тот же порт через мультиплексирование. Я не знаю о нем толком ничего, просто запомнилось, что такая возможность есть.

    P.S. Ограничение в 65k портов связано с тем, что в TCP-слое пакета под порт выделено 16 бит.
    Ответ написан
    1 комментарий