I agree, it s very frustrating and time consuming. Almost impossible to get it right. I may try the OSGi R7, but I am not sure of its adoption level at this time, availability of bundles, examples, support by Karaf, etc.
Anyway, back to my current stack. I only see one DataSource being registered: karaf@root()> service:list DataSource [javax.sql.DataSource] ---------------------- databaseName = responder dataSourceName = responder osgi.jdbc.driver.name = mariadb osgi.jndi.service.name = responder service.bundleid = 14 service.factoryPid = org.ops4j.datasource service.id = 194 service.pid = org.ops4j.datasource.feb33f6d-dc46-4bc7-a417-ad6bdd5a6ee5 service.scope = singleton url = jdbc:mariadb:XXXXXX Provided by : OPS4J Pax JDBC Config (14) Used by: Data (135) Not sure what to do with this. I specified the following in the configuration: pool=narayana xa=true Best regards, Alex soto > On May 16, 2018, at 4:12 PM, Tim Ward <[email protected]> wrote: > > The structure of the JNDI name is defined by the JNDI service specification. > > osgi:service/<interface name>[/<filter>] > > So in this case both of your services should be DataSource instances, but > they should have different filters. > > The important thing is to make sure you have an JTA enlisting DataSource > registered as a service (this isn’t just your normal DataSource), then to > build a filter which selects that. One option for this is to use the > enlistment whiteboard from Aries (not well documented) > https://github.com/apache/aries/tree/trunk/transaction/transaction-jdbc > <https://github.com/apache/aries/tree/trunk/transaction/transaction-jdbc> > > This is a non-trivial thing to do, which is why I keep mentioning Transaction > Control which handles the enlistment reliably without the layers of services. > > Best Regards, > > Tim > > Sent from my iPhone > > On 16 May 2018, at 21:57, Alex Soto <[email protected] > <mailto:[email protected]>> wrote: > >> Thank you Tim. >> >> Any idea what the JNDI names would be? >> It is Pax-JDBC creating these JNDI names, so I have no idea. >> >> From the Karaf console: >> >> >> karaf@root()> jndi:names >> JNDI Name │ Class Name >> ───────────────────────┼─────────────────────────────────────────────── >> osgi:service/responder │ org.mariadb.jdbc.MySQLDataSource >> osgi:service/jndi │ org.apache.karaf.jndi.internal.JndiServiceImpl >> >> >> Best regards, >> Alex soto >> >> >> >> >>> On May 16, 2018, at 3:48 PM, Tim Ward <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Just looking quickly. >>> >>> You have the same JNDI name for both JTA and non JTA DataSources. This is >>> clearly wrong as the DataSource cannot simultaneously be enlisted in the >>> Transaction and not enlisted. The comments also indicate a misunderstanding >>> of the purpose of the non-jta-datasource, which absolutely is used with JTA >>> EntityManagers (for things like sequence allocation and out of band >>> optimisations). You really do need to have both and they do need to behave >>> differently. >>> >>> At a guess your DataSource is not enlisted with the transaction manager >>> present in the system. This usually happens by configuring a (otherwise >>> invisible) DataSource wrapper There is nothing forcing you to make this >>> happen (or checking that it does) hence your transactions would be broken. >>> This is one of the several reasons I try to direct people to Transaction >>> Control where the model actively pushes you toward transactions that >>> actually work, rather than hiding all the magic behind an annotation. >>> >>> Hopefully this gives you some clues as to what might be wrong. >>> >>> Best Regards, >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 16 May 2018, at 21:34, Jean-Baptiste Onofré <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Are you sure about your code ? Flush looks weird to me and it seems you >>>> don't use container managed transaction. >>>> >>>> Regards >>>> JB >>>> >>>>> On 16/05/2018 21:08, Alex Soto wrote: >>>>> Yes, same result. I even tried with Narayana Transaction Manager, and >>>>> same result. >>>>> Best regards, >>>>> Alex soto >>>>>> On May 16, 2018, at 2:56 PM, Jean-Baptiste Onofré <[email protected] >>>>>> <mailto:[email protected]> <mailto:[email protected] >>>>>> <mailto:[email protected]>>> wrote: >>>>>> >>>>>> Same behavior with RequiresNew ? >>>>>> >>>>>> Regards >>>>>> JB >>>>>> >>>>>>> On 16/05/2018 19:44, Alex Soto wrote: >>>>>>> With Karaf version 4.2.0, Rollback is not working with MariaDB and >>>>>>> InnoDB tables. >>>>>>> I deployed these features (from Karaf’s enterprise repository): >>>>>>> <feature>aries-blueprint</feature> >>>>>>> <feature>transaction</feature> >>>>>>> <feature>jndi</feature> >>>>>>> <feature>jdbc</feature> >>>>>>> <feature>jpa</feature> >>>>>>> <feature>pax-jdbc-mariadb</feature> >>>>>>> <feature>pax-jdbc-config</feature> >>>>>>> <feature>pax-jdbc-pool-dbcp2</feature> >>>>>>> <feature>hibernate</feature> >>>>>>> My Data Source is configured in the file >>>>>>> /org.ops4j.datasource-responder.cfg/ >>>>>>> osgi.jdbc.driver.name = mariadb >>>>>>> dataSourceName=responder >>>>>>> url >>>>>>> = >>>>>>> jdbc:mariadb://mariadb.local:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true&autocommit=false >>>>>>> >>>>>>> <mariadb://mariadb.local:3306/responder?characterEncoding=UTF-8&useServerPrepStmts=true&autocommit=false> >>>>>>> user=XXXX >>>>>>> password=XXXX >>>>>>> databaseName=responder >>>>>>> #Pool Config >>>>>>> pool=dbcp2 >>>>>>> xa=true >>>>>>> My persistence.xml: >>>>>>> <persistence version="2.0" >>>>>>> xmlns="http://java.sun.com/xml/ns/persistence >>>>>>> <http://java.sun.com/xml/ns/persistence>" >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance >>>>>>> <http://www.w3.org/2001/XMLSchema-instance>" >>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence >>>>>>> <http://java.sun.com/xml/ns/persistence> >>>>>>> http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd >>>>>>> <http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd>"> >>>>>>> <persistence-unit name="responderPersistenUnit" >>>>>>> transaction-type="JTA"> >>>>>>> >>>>>>> <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> >>>>>>> <!-- Only used when transaction-type=JTA --> >>>>>>> >>>>>>> <jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</jta-data-source> >>>>>>> <!-- Only used when transaction-type=RESOURCE_LOCAL --> >>>>>>> >>>>>>> <non-jta-data-source>osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=responder)</non-jta-data-source> >>>>>>> <properties> >>>>>>> <property name=“hibernate.dialect" >>>>>>> value="org.hibernate.dialect.MySQL5Dialect" /> >>>>>>> <property name="hibernate.show_sql" value="true" /> >>>>>>> <property name="hibernate.format_sql" value="true" /> >>>>>>> <property name="hibernate.hbm2ddl.auto" value="none"/> >>>>>>> </properties> >>>>>>> </persistence-unit> >>>>>>> </persistence> >>>>>>> My blueprint.xml: >>>>>>> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0 >>>>>>> <http://www.osgi.org/xmlns/blueprint/v1.0.0>" >>>>>>> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0 >>>>>>> <http://aries.apache.org/xmlns/jpa/v2.0.0>" >>>>>>> xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0 >>>>>>> <http://aries.apache.org/xmlns/transactions/v2.0.0>" >>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance >>>>>>> <http://www.w3.org/2001/XMLSchema-instance>" >>>>>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 >>>>>>> <http://www.osgi.org/xmlns/blueprint/v1.0.0> >>>>>>> https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd >>>>>>> <https://osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd>"> >>>>>>> <jpa:enable /> >>>>>>> <tx:enable /> >>>>>>> <bean id="userService" class="org.data.impl.UserServiceImpl" /> >>>>>>> <service ref="userService" interface="org.data.UserService" /> >>>>>>> </blueprint> >>>>>>> For testing I throw exception in my DAO: >>>>>>> @Transactional(REQUIRED) >>>>>>> public void addUser(User user) { >>>>>>> em.persist(user); >>>>>>> em.flush(); >>>>>>> throw new RuntimeException("On Purpose"); >>>>>>> } >>>>>>> I expect the record not to be in the table due to rollback of the >>>>>>> transaction, but it still shows up in my database table. >>>>>>> Best regards, >>>>>>> Alex soto >>
