You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by jochenw <jo...@googlemail.com> on 2016/07/11 07:37:46 UTC
Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Hello,
start levels have been removed for a number of bundles in the Karaf
enterprise features. In principle a good idea (sometimes start levels are
even seen as anti-pattern in OSGi).
However, sometimes I now face the issue that the transaction service is
missing when one of my persistence bundle start up, and some initial writing
to the DB fails (currently, I don't have the stack trace available, but it
says "no transaction associated with this thread"). Is does not happen every
time (looks more frequent if the machine is busy with other things, or on
devices with restricted computing power). Giving the data source /
persistence bundles higher start levels than 80 does not help.
I'm using pax-jdbc to create the data source (however, not pax-jdbc-config,
since also that turned out too slow sometimes to create the data sources
before the persistence bundles started).
Might be a dumb question: how can make the data source bundle (data source
created via blueprint.xml) waiting for the transaction manager being
available? And / or (even better, since then I could switch to using
pax-jdbc-config for creation of the data source): how can I make my
persistence bundles waiting for the datasource being available? I only have
the blueprint.xml (for the data source) and the persistence.xml (for the
persistence unit), and currently don't see a possibility to make them wait
for their dependencies.
Currently, I'm using JPA 1.0.4, transaction 1.3.0.
From my datasource blueprint.xml:
<bean id="myXADataSource"
class="org.apache.commons.dbcp2.managed.BasicManagedDataSource"
destroy-method="close">
<property name="url" value="${url}" />
<property name="username" value="${userName}" />
<property name="password" value="${password}" />
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="initialSize" value="10" />
<property name="maxTotal" value="50" />
<property name="maxIdle" value="20" />
<property name="transactionManager" ref="transactionManager" />
</bean>
<reference id="transactionManager"
interface="javax.transaction.TransactionManager" />
Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Posted by Guillaume Nodet <gn...@apache.org>.
The depend-on flag on the bean element can be used for that.
The JPA 2.x Aries bundles should solve the service dependency problem and
be better integrated with the pax-jdbc config stuff.
2016-07-11 9:37 GMT+02:00 jochenw <jo...@googlemail.com>:
> Hello,
>
> start levels have been removed for a number of bundles in the Karaf
> enterprise features. In principle a good idea (sometimes start levels are
> even seen as anti-pattern in OSGi).
>
> However, sometimes I now face the issue that the transaction service is
> missing when one of my persistence bundle start up, and some initial
> writing
> to the DB fails (currently, I don't have the stack trace available, but it
> says "no transaction associated with this thread"). Is does not happen
> every
> time (looks more frequent if the machine is busy with other things, or on
> devices with restricted computing power). Giving the data source /
> persistence bundles higher start levels than 80 does not help.
>
> I'm using pax-jdbc to create the data source (however, not pax-jdbc-config,
> since also that turned out too slow sometimes to create the data sources
> before the persistence bundles started).
>
> Might be a dumb question: how can make the data source bundle (data source
> created via blueprint.xml) waiting for the transaction manager being
> available? And / or (even better, since then I could switch to using
> pax-jdbc-config for creation of the data source): how can I make my
> persistence bundles waiting for the datasource being available? I only have
> the blueprint.xml (for the data source) and the persistence.xml (for the
> persistence unit), and currently don't see a possibility to make them wait
> for their dependencies.
>
> Currently, I'm using JPA 1.0.4, transaction 1.3.0.
>
> From my datasource blueprint.xml:
>
> <bean id="myXADataSource"
> class="org.apache.commons.dbcp2.managed.BasicManagedDataSource"
> destroy-method="close">
> <property name="url" value="${url}" />
> <property name="username" value="${userName}" />
> <property name="password" value="${password}" />
> <property name="driverClassName"
> value="org.postgresql.Driver" />
> <property name="initialSize" value="10" />
> <property name="maxTotal" value="50" />
> <property name="maxIdle" value="20" />
> <property name="transactionManager"
> ref="transactionManager" />
> </bean>
>
> <reference id="transactionManager"
> interface="javax.transaction.TransactionManager" />
>
>
> Regards,
> Jochen
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Tim,
you should create such a feature in the tx-control code in Aries. For
example the Aries jpa code already has such a feature now.
This allows people to install their desired version independently from
the karaf version.
As soon as you have this feature I can then add it to the karaf short
list to make it easier to install it.
For example you can install aries jpa using
feature:repo-add aries-jpa 2.4.0
instead of
feature:repo-add mvn:org.apache.aries.jpa/jpa-features/2.4.0/xml/features
It could be like
feature:install aries-tx-control 1.0.0
Christian
On 18.07.2016 11:31, Timothy Ward wrote:
> Hi Jochen,
>
> Sorry I missed this reply last week, I only noticed it after Guillaume\u2019s reply.
>
> I\u2019m not a Karaf committer, nor do I actually use Karaf, so there is no Karaf feature for Transaction Control as yet. I know that some people have been playing with it though, and it should be pretty easy to put one together.
>
> The local and XA transaction control services are both independently deployable (you\u2019ll only want one of them).
>
> <dependency>
> <groupId>org.apache.aries.tx-control</groupId>
> <artifactId>tx-control-service-local</artifactId>
> <version>0.0.1</version>
> </dependency>
>
> And you\u2019ll also want a JPA Resource provider to give you JPA support:
>
> <dependency>
> <groupId>org.apache.aries.tx-control</groupId>
> <artifactId>tx-control-provider-jdbc-local</artifactId>
> <version>0.0.1</version>
> </dependency>
>
> This depends on having a JPA container (Aries JPA 2.4.0 works well) and a JPA provider (it\u2019s tested with EclipseLink, Hibernate and OpenJPA.
>
>
>> I haven't looked into the
>> transaction control service up to now, and don't know whether e.g. the
>> persistence bundles can stay as they are.
>
> Yes, the JPA support builds on the JPA service, so persistence bundles (i.e. bundles with Meta-Persistence) should be packaged in the same way.
>
>> Since we already are pretty close to a
>> release date, we'd rather like not to change code. However, it might be naiv
>> to think that such an easy exchange is possible
> It won\u2019t be directly possible. Transaction control is an explicit transaction management framework, and does require some code to define the transactional work. You will also need to obtain your EntityManager instances using a JPAEntityManagerProvider service.
>
> These changes are not large (a few lines of code) but they are necessary.
>
> Regards,
>
> Tim
>
>> On 11 Jul 2016, at 17:17, jochenw <jo...@googlemail.com> wrote:
>>
>> Hi Timothy,
>>
>> sounds interesting. Is there a description which Karaf features to use to
>> replace the "transaction" feature? Since we already are pretty close to a
>> release date, we'd rather like not to change code. However, it might be naiv
>> to think that such an easy exchange is possible - I haven't looked into the
>> transaction control service up to now, and don't know whether e.g. the
>> persistence bundles can stay as they are.
>>
>>
>> Guillaume, here from the persistence.xml:
>>
>> <persistence-unit name=xyz.persistence"
>> transaction-type="JTA">
>>
>> <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myXADataSource)
>> </jta-data-source>
>>
>> <non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myDataSource)
>> </non-jta-data-source>
>> <mapping-file>META-INF/orm.xml</mapping-file>
>> <class>someclass</class>
>> ....
>> <exclude-unlisted-classes>true</exclude-unlisted-classes>
>> <properties>
>> <property name="eclipselink.logging.level" value="SEVERE" />
>> <property name="eclipselink.weaving" value="true" />
>> <property name="eclipselink.ddl-generation"
>> value="create-or-extend-tables" />
>> <property name="eclipselink.ddl-generation.output-mode"
>> value="database" />
>> <property name="eclipselink.target-database"
>> value="org.eclipse.persistence.platform.database.PostgreSQLPlatform" />
>> </properties>
>> </persistence-unit>
>>
>>
>> and from the blueprint.xml:
>>
>>
>>
>> <service ref="myDAO"
>> interface="org.test.myDAOIF" />
>>
>>
>>
>> <bean id="myDAO"
>> class="org.test.myDAO"
>> scope="singleton">
>> <jpa:context unitname="xyz.persistence"
>> property="entityManager" />
>> <tx:transaction method="*" value="Required" />
>> </bean>
>>
>>
>> Currently we are forced to stay with Aries JPA 1.x, since our persistence
>> bundles do not yet define the persistence units via annotation - having a
>> growing and very well distributed project. If JPA 1.x + transaction manager
>> has known deficienciey regarding handling of service dynamism, then it could
>> be argued whether start levels have been removed anyways (although they are
>> bad style, it might allow a smooth transition when leaving them in for older
>> versions and setting these to deprecated, instead of causing them not
>> working correctly by removing the start levels). However, from previous
>> discussions I have understood that our problems might not be so common, so
>> nobody else might have stumbled over them.
>>
>> Regards,
>> Jochen
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189p4047199.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction manager not available in time
Posted by Tim Ward <ti...@paremus.com>.
Hi Jochen,
Sent from my iPhone
> On 27 Jul 2016, at 07:47, jochenw <jo...@googlemail.com> wrote:
>
> Hi Tim,
>
> the transaction control service sounds interesting. I haven't found some
> example or tutorial which shows how to used it with JPA. Do you know whether
> something like this exists? Would be helpful to get started. I'm sure that
> the documentation pages contain all relevant information, but from an
> example it would be easier to see how to put all this together.
As the Transaction Control service is pretty new (the RFC started in January and the first Aries release was in June) there aren't many examples out there. The docs are pretty good by Aries standards, and I'd be keen to know what extra you'd like to see there.
As for what you need to do, you just need to inject a JPAEntityManagerProvider and a TransactionControl into your DAO and combine them into an EntityManager. The whole thing then works just like the JDBC examples (i.e. define your scope using transaction control and use the EntityManager normally).
The JPA persistence XML can be basically empty (just a name) and pointed at by a Meta-Persistence header. You can then do all the setup with a configuration as described here.
http://aries.apache.org/modules/tx-control/xaJPA.html
Tim
>
> Regarding the karaf feature: as Christian wrote, it wouldn't be needed to
> include that to the basic Karaf enterprise feature file. But is the package
> would have a Karaf feature file on its own, one could just include it to a
> custom Karaf composition using the karaf-maven-plugin. Already possible e.g.
> for ActiveMQ, Camel, Shiro, CXF etc. etc. etc.
>
> We are planning to switch to JPA 2.x to solve our most urgent issues. Is in
> principle a small change, however, it needs some special handling when using
> a base class for the DAOs which contains the basic operations, since it is
> not possible to define the EntityManager in the base class (not for classes
> sharing the same persistence unit due to some bug in the framework - don't
> know whether that has been solved inbetween, and of course not if the base
> class should be used by classes which use different persistence units).
>
> Regards,
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189p4047341.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Posted by jochenw <jo...@googlemail.com>.
Hi Tim,
the transaction control service sounds interesting. I haven't found some
example or tutorial which shows how to used it with JPA. Do you know whether
something like this exists? Would be helpful to get started. I'm sure that
the documentation pages contain all relevant information, but from an
example it would be easier to see how to put all this together.
Regarding the karaf feature: as Christian wrote, it wouldn't be needed to
include that to the basic Karaf enterprise feature file. But is the package
would have a Karaf feature file on its own, one could just include it to a
custom Karaf composition using the karaf-maven-plugin. Already possible e.g.
for ActiveMQ, Camel, Shiro, CXF etc. etc. etc.
We are planning to switch to JPA 2.x to solve our most urgent issues. Is in
principle a small change, however, it needs some special handling when using
a base class for the DAOs which contains the basic operations, since it is
not possible to define the EntityManager in the base class (not for classes
sharing the same persistence unit due to some bug in the framework - don't
know whether that has been solved inbetween, and of course not if the base
class should be used by classes which use different persistence units).
Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189p4047341.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction manager not available in time
Posted by Timothy Ward <ti...@paremus.com>.
Hi Jochen,
Sorry I missed this reply last week, I only noticed it after Guillaume’s reply.
I’m not a Karaf committer, nor do I actually use Karaf, so there is no Karaf feature for Transaction Control as yet. I know that some people have been playing with it though, and it should be pretty easy to put one together.
The local and XA transaction control services are both independently deployable (you’ll only want one of them).
<dependency>
<groupId>org.apache.aries.tx-control</groupId>
<artifactId>tx-control-service-local</artifactId>
<version>0.0.1</version>
</dependency>
And you’ll also want a JPA Resource provider to give you JPA support:
<dependency>
<groupId>org.apache.aries.tx-control</groupId>
<artifactId>tx-control-provider-jdbc-local</artifactId>
<version>0.0.1</version>
</dependency>
This depends on having a JPA container (Aries JPA 2.4.0 works well) and a JPA provider (it’s tested with EclipseLink, Hibernate and OpenJPA.
> I haven't looked into the
> transaction control service up to now, and don't know whether e.g. the
> persistence bundles can stay as they are.
Yes, the JPA support builds on the JPA service, so persistence bundles (i.e. bundles with Meta-Persistence) should be packaged in the same way.
> Since we already are pretty close to a
> release date, we'd rather like not to change code. However, it might be naiv
> to think that such an easy exchange is possible
It won’t be directly possible. Transaction control is an explicit transaction management framework, and does require some code to define the transactional work. You will also need to obtain your EntityManager instances using a JPAEntityManagerProvider service.
These changes are not large (a few lines of code) but they are necessary.
Regards,
Tim
> On 11 Jul 2016, at 17:17, jochenw <jo...@googlemail.com> wrote:
>
> Hi Timothy,
>
> sounds interesting. Is there a description which Karaf features to use to
> replace the "transaction" feature? Since we already are pretty close to a
> release date, we'd rather like not to change code. However, it might be naiv
> to think that such an easy exchange is possible - I haven't looked into the
> transaction control service up to now, and don't know whether e.g. the
> persistence bundles can stay as they are.
>
>
> Guillaume, here from the persistence.xml:
>
> <persistence-unit name=xyz.persistence"
> transaction-type="JTA">
>
> <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myXADataSource)
> </jta-data-source>
>
> <non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myDataSource)
> </non-jta-data-source>
> <mapping-file>META-INF/orm.xml</mapping-file>
> <class>someclass</class>
> ....
> <exclude-unlisted-classes>true</exclude-unlisted-classes>
> <properties>
> <property name="eclipselink.logging.level" value="SEVERE" />
> <property name="eclipselink.weaving" value="true" />
> <property name="eclipselink.ddl-generation"
> value="create-or-extend-tables" />
> <property name="eclipselink.ddl-generation.output-mode"
> value="database" />
> <property name="eclipselink.target-database"
> value="org.eclipse.persistence.platform.database.PostgreSQLPlatform" />
> </properties>
> </persistence-unit>
>
>
> and from the blueprint.xml:
>
>
>
> <service ref="myDAO"
> interface="org.test.myDAOIF" />
>
>
>
> <bean id="myDAO"
> class="org.test.myDAO"
> scope="singleton">
> <jpa:context unitname="xyz.persistence"
> property="entityManager" />
> <tx:transaction method="*" value="Required" />
> </bean>
>
>
> Currently we are forced to stay with Aries JPA 1.x, since our persistence
> bundles do not yet define the persistence units via annotation - having a
> growing and very well distributed project. If JPA 1.x + transaction manager
> has known deficienciey regarding handling of service dynamism, then it could
> be argued whether start levels have been removed anyways (although they are
> bad style, it might allow a smooth transition when leaving them in for older
> versions and setting these to deprecated, instead of causing them not
> working correctly by removing the start levels). However, from previous
> discussions I have understood that our problems might not be so common, so
> nobody else might have stumbled over them.
>
> Regards,
> Jochen
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189p4047199.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Posted by jochenw <jo...@googlemail.com>.
Hi Timothy,
sounds interesting. Is there a description which Karaf features to use to
replace the "transaction" feature? Since we already are pretty close to a
release date, we'd rather like not to change code. However, it might be naiv
to think that such an easy exchange is possible - I haven't looked into the
transaction control service up to now, and don't know whether e.g. the
persistence bundles can stay as they are.
Guillaume, here from the persistence.xml:
<persistence-unit name=xyz.persistence"
transaction-type="JTA">
<jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myXADataSource)
</jta-data-source>
<non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/myDataSource)
</non-jta-data-source>
<mapping-file>META-INF/orm.xml</mapping-file>
<class>someclass</class>
....
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="eclipselink.logging.level" value="SEVERE" />
<property name="eclipselink.weaving" value="true" />
<property name="eclipselink.ddl-generation"
value="create-or-extend-tables" />
<property name="eclipselink.ddl-generation.output-mode"
value="database" />
<property name="eclipselink.target-database"
value="org.eclipse.persistence.platform.database.PostgreSQLPlatform" />
</properties>
</persistence-unit>
and from the blueprint.xml:
<service ref="myDAO"
interface="org.test.myDAOIF" />
<bean id="myDAO"
class="org.test.myDAO"
scope="singleton">
<jpa:context unitname="xyz.persistence"
property="entityManager" />
<tx:transaction method="*" value="Required" />
</bean>
Currently we are forced to stay with Aries JPA 1.x, since our persistence
bundles do not yet define the persistence units via annotation - having a
growing and very well distributed project. If JPA 1.x + transaction manager
has known deficienciey regarding handling of service dynamism, then it could
be argued whether start levels have been removed anyways (although they are
bad style, it might allow a smooth transition when leaving them in for older
versions and setting these to deprecated, instead of causing them not
working correctly by removing the start levels). However, from previous
discussions I have understood that our problems might not be so common, so
nobody else might have stumbled over them.
Regards,
Jochen
--
View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189p4047199.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction manager not available in time
Posted by Timothy Ward <ti...@paremus.com>.
Hi Jochen,
You’re absolutely right that start levels (and startup ordering) are anti-patterns in OSGi.
It’s also the case that Aries Transaction and older versions of Aries JPA (the 1.x releases) are really hard to use. Aries JPA 1.x does not always wait correctly for the datasources that it needs, and Aries Transaction uses lots of service property mangling to identify the “transactional datasource”.
I can strongly recommend that you look at the OSGi Transaction Control service as a better, simpler, persistence management framework for OSGi. This is currently defined in a public RFC https://github.com/osgi/design/blob/master/rfcs/rfc0221/rfc-0221-TransactionControl.pdf <https://github.com/osgi/design/blob/master/rfcs/rfc0221/rfc-0221-TransactionControl.pdf> and there is an implementation in Apache Aries http://aries.apache.org/modules/transactioncontrol.html <http://aries.apache.org/modules/transactioncontrol.html>
One of the primary goals of Transaction Control is to completely avoid the lifecycle confusion that frequently occurs with transaction management in OSGi. The JPA Resource provider in the Aries Tx Control projects will also ensure that you never have to worry about whether the Transaction Manager got wired in correctly or not. It’s tested against EclipseLink, OpenJPA and Hibernate, and you can either use Local Transactions or XA transactions as needed.
I’d be happy to answer any questions that you have.
Best Regards,
Tim Ward
OSGi IoT Expert Group Chair
tim.ward@paremus.com
> On 11 Jul 2016, at 08:37, jochenw <jo...@googlemail.com> wrote:
>
> Hello,
>
> start levels have been removed for a number of bundles in the Karaf
> enterprise features. In principle a good idea (sometimes start levels are
> even seen as anti-pattern in OSGi).
>
> However, sometimes I now face the issue that the transaction service is
> missing when one of my persistence bundle start up, and some initial writing
> to the DB fails (currently, I don't have the stack trace available, but it
> says "no transaction associated with this thread"). Is does not happen every
> time (looks more frequent if the machine is busy with other things, or on
> devices with restricted computing power). Giving the data source /
> persistence bundles higher start levels than 80 does not help.
>
> I'm using pax-jdbc to create the data source (however, not pax-jdbc-config,
> since also that turned out too slow sometimes to create the data sources
> before the persistence bundles started).
>
> Might be a dumb question: how can make the data source bundle (data source
> created via blueprint.xml) waiting for the transaction manager being
> available? And / or (even better, since then I could switch to using
> pax-jdbc-config for creation of the data source): how can I make my
> persistence bundles waiting for the datasource being available? I only have
> the blueprint.xml (for the data source) and the persistence.xml (for the
> persistence unit), and currently don't see a possibility to make them wait
> for their dependencies.
>
> Currently, I'm using JPA 1.0.4, transaction 1.3.0.
>
> From my datasource blueprint.xml:
>
> <bean id="myXADataSource"
> class="org.apache.commons.dbcp2.managed.BasicManagedDataSource"
> destroy-method="close">
> <property name="url" value="${url}" />
> <property name="username" value="${userName}" />
> <property name="password" value="${password}" />
> <property name="driverClassName" value="org.postgresql.Driver" />
> <property name="initialSize" value="10" />
> <property name="maxTotal" value="50" />
> <property name="maxIdle" value="20" />
> <property name="transactionManager" ref="transactionManager" />
> </bean>
>
> <reference id="transactionManager"
> interface="javax.transaction.TransactionManager" />
>
>
> Regards,
> Jochen
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Removal of start levels from Karaf 4.0.2 onwards - transaction
manager not available in time
Posted by Guillaume Nodet <gn...@apache.org>.
Could you give a bit more information on how your persistence bundle is
used ?
The EntityManager / EntityManagerFactory should only be available in the
OSGi registry once everything is ready...
2016-07-11 9:37 GMT+02:00 jochenw <jo...@googlemail.com>:
> Hello,
>
> start levels have been removed for a number of bundles in the Karaf
> enterprise features. In principle a good idea (sometimes start levels are
> even seen as anti-pattern in OSGi).
>
> However, sometimes I now face the issue that the transaction service is
> missing when one of my persistence bundle start up, and some initial
> writing
> to the DB fails (currently, I don't have the stack trace available, but it
> says "no transaction associated with this thread"). Is does not happen
> every
> time (looks more frequent if the machine is busy with other things, or on
> devices with restricted computing power). Giving the data source /
> persistence bundles higher start levels than 80 does not help.
>
> I'm using pax-jdbc to create the data source (however, not pax-jdbc-config,
> since also that turned out too slow sometimes to create the data sources
> before the persistence bundles started).
>
> Might be a dumb question: how can make the data source bundle (data source
> created via blueprint.xml) waiting for the transaction manager being
> available? And / or (even better, since then I could switch to using
> pax-jdbc-config for creation of the data source): how can I make my
> persistence bundles waiting for the datasource being available? I only have
> the blueprint.xml (for the data source) and the persistence.xml (for the
> persistence unit), and currently don't see a possibility to make them wait
> for their dependencies.
>
> Currently, I'm using JPA 1.0.4, transaction 1.3.0.
>
> From my datasource blueprint.xml:
>
> <bean id="myXADataSource"
> class="org.apache.commons.dbcp2.managed.BasicManagedDataSource"
> destroy-method="close">
> <property name="url" value="${url}" />
> <property name="username" value="${userName}" />
> <property name="password" value="${password}" />
> <property name="driverClassName"
> value="org.postgresql.Driver" />
> <property name="initialSize" value="10" />
> <property name="maxTotal" value="50" />
> <property name="maxIdle" value="20" />
> <property name="transactionManager"
> ref="transactionManager" />
> </bean>
>
> <reference id="transactionManager"
> interface="javax.transaction.TransactionManager" />
>
>
> Regards,
> Jochen
>
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Removal-of-start-levels-from-Karaf-4-0-2-onwards-transaction-manager-not-available-in-time-tp4047189.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/