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.w...@paremus.com > On 11 Jul 2016, at 08:37, jochenw <jochen.walz.m...@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.
