только создается ServiceFactory а не сам сервис, я писал выше. Как только никто не использует этот сервис, в ServiceFactory разрушается EMF. В этом то и дело что SCR (Declarative Services) как раз и работают имено через SF.
Декларативный сервис тем и полезен, что создается по требованию, когда из ServiceReferenсe требуем сам сервис. Как только сервис освобождается, с помощью ungetService, он сразу разрушается.
Это не совсем верно, точнее это верно только для DelayedComponent, и то в зависимости от настроек. Для остальных например в SCR примерно следующий код:
public void ungetService(Bundle bundle, ServiceRegistration registration, Object service) {
if(usesCount.get() > 0){
long usesCountNow = usesCount.decrementAndGet();
log.debug("== Uses count of {} service are {}", original.getClass(), usesCountNow);
}
}
Реализуется это все через ServiceFactory.
/**
* Allows services to provide customized service objects in the OSGi
* environment.
*
* <p>
* When registering a service, a {@code ServiceFactory} object can be used
* instead of a service object, so that the bundle developer can gain control of
* the specific service object granted to a bundle that is using the service.
*
* <p>
* When this happens, the {@code BundleContext.getService(ServiceReference)}
* method calls the {@code ServiceFactory.getService} method to create a service
* object specifically for the requesting bundle. The service object returned by
* the {@code ServiceFactory} is cached by the Framework until the bundle
* releases its use of the service.
*
* <p>
* When the bundle's use count for the service is decremented to zero (including
* the bundle stopping or the service being unregistered), the
* {@code ServiceFactory.ungetService} method is called.
*
* <p>
* {@code ServiceFactory} objects are only used by the Framework and are not
* made available to other bundles in the OSGi environment. The Framework may
* concurrently call a {@code ServiceFactory}.
*
* @param <S> Type of Service
* @see BundleContext#getService(ServiceReference)
* @ThreadSafe
* @version $Id: 535776e702ec5ace54f577218ff8f7920741558b $
*/
public interface ServiceFactory<S> {
На выгрузке классов никто не экономит, вот посмотрел на работаюший пару месяцев сервис там как загрузились 2,5к классов так и остались загруженными, если выгрузить бандл классы этого бандла будут выгружены, в противном случае они останутся загруженными.
А вот выгрузка класса произойдет только тогда когда не будет на него ссылок, а ссылки остануться как минимум в бандле после первой загрузки, потому что каждый бандл внутрни себя содержит свой класслоадер, и если посмотреть на реализацию например в felix (org.apache.felix.framework.BundleWiringImpl.BundleClassLoader) он наследуется от java.lang.ClassLoader в котором загруженные классы попадают в кеш, соотвествеено они соберуться только после того как пропадут ссылки на класслоадер, а на него пропадут ссылки после деинсталяции бандла (судя по коду).
Все почти так. EM нужно создавать в контексте открытой транзакции, в этом случае к EM она будет привязана. Даже проще говоря нужно открыть Connection и он будет к привязан к тразакции, а уже к Connection будет привязан EntityManager. (и может быть как XA так и простой)
Как в вашем примере, будет создано ровно тоже самое, будет открыто новое соединение, и оно будет привязано к транзакции.
Простейший пример:
Есть JTADataSource (например org.apache.commons.dbcp2.managed.BasicManagedDataSource)
Есть TM
Внутри DataSourceFactory проверяется есть ли доступный TransactionManager (мы используем geromnio tm) и возвращается декорированный DS.
Далее вешается листенер на старт бандлов (org.osgi.framework.BundleListener) и проверяется наличиее мета тега Meta-Persistence
При нахождении этого тега берется persistence.xml и начинается инициализации EMF
1. Формируется смешанный класслоадер для конкретной реализации JPA (eclipselink или hibernate) и бандла с ресурсом persistence.xml
2. Формируется DataSource из настроек в persistence.xml и переопределений в системных настройках.
3. Выбирается стратегия использования транзакций
4. Вместо конкретной инициализации EMF подсовываем прокси EMF который в свою очередь имплементирует org.osgi.framework.ServiceFactory
4.1 Далее на первый вызов getService(Bundle bundle, ServiceRegistration registration) инстациируется сам EMF и увеличивается счетчик ссылок на сервис
4.2 На вызов метода ungetService(Bundle bundle, ServiceRegistration registration, Object service) происходит провека количества ссылок на сервис и если оно равно нулю то EMF уничтожается.
Внутри спрятано еще достаточно много деталей (как отрабатывает рестарт бандла с провайдером, с ресурсом), но концепция в двух словах должна быть понятна.
Idea только проверяет корректность, в ней указываются маркеры-аннотации для проверок. Автор же использует аннотации из findbugs, но можно свои написать и использовать с тем же успехом.
Для RTMP не обязателен Adobe Flash Media Server, есть альтернативы в виде Red5, rtmpd, Wowza и другие…
В качестве RTMFP совместимого сервиса, точнее регистратора потоков, может выступать не только FMS4 или Cirrus, мы используем простой сервис Cumulus. В нем есть ряд проблем, но для передачи видео потоков между пользователями напряму более чем подходит.
В целом RTMFP местами сильно упрощает разработку сложных сервисов, но целиком без централизованного управления не обойтись. Простой пример: есть централизированный сервис видео конф. и есть два филиала, которые к нему подключены, общение между филиалами удобнее делать через центральный сервис, а обмен внутри офиса выгоднее делать через пиринговую сеть.
На самом деле она изначально кластерная. Посмотрите внимательно ;) Отсутствие Listener'ов на высоком уровне не означает что их нет на более низком, там используется общая мапа для hazelcast cluster. В конструкторе класса HazelcastCache как раз и берется инстанс cache = Hazelcast.getMap(regionName); Из видео становится понятней что из себя представляет Hazelcast впринципе www.hazelcast.com/gettingstarted.htm.
Это не совсем верно, точнее это верно только для DelayedComponent, и то в зависимости от настроек. Для остальных например в SCR примерно следующий код:
Реализуется это все через ServiceFactory.
На выгрузке классов никто не экономит, вот посмотрел на работаюший пару месяцев сервис там как загрузились 2,5к классов так и остались загруженными, если выгрузить бандл классы этого бандла будут выгружены, в противном случае они останутся загруженными.
Как в вашем примере, будет создано ровно тоже самое, будет открыто новое соединение, и оно будет привязано к транзакции.
Простейший пример:
Есть JTADataSource (например org.apache.commons.dbcp2.managed.BasicManagedDataSource)
Есть TM
1. Формируется смешанный класслоадер для конкретной реализации JPA (eclipselink или hibernate) и бандла с ресурсом persistence.xml
2. Формируется DataSource из настроек в persistence.xml и переопределений в системных настройках.
3. Выбирается стратегия использования транзакций
4. Вместо конкретной инициализации EMF подсовываем прокси EMF который в свою очередь имплементирует org.osgi.framework.ServiceFactory
4.1 Далее на первый вызов getService(Bundle bundle, ServiceRegistration registration) инстациируется сам EMF и увеличивается счетчик ссылок на сервис
4.2 На вызов метода ungetService(Bundle bundle, ServiceRegistration registration, Object service) происходит провека количества ссылок на сервис и если оно равно нулю то EMF уничтожается.
Внутри спрятано еще достаточно много деталей (как отрабатывает рестарт бандла с провайдером, с ресурсом), но концепция в двух словах должна быть понятна.
В качестве RTMFP совместимого сервиса, точнее регистратора потоков, может выступать не только FMS4 или Cirrus, мы используем простой сервис Cumulus. В нем есть ряд проблем, но для передачи видео потоков между пользователями напряму более чем подходит.
В целом RTMFP местами сильно упрощает разработку сложных сервисов, но целиком без централизованного управления не обойтись. Простой пример: есть централизированный сервис видео конф. и есть два филиала, которые к нему подключены, общение между филиалами удобнее делать через центральный сервис, а обмен внутри офиса выгоднее делать через пиринговую сеть.
code.google.com/p/hazelcast/source/browse/#svn/trunk/hazelcast-hibernate%3Fstate%3Dclosed