Hi Alex, I fully agree, and we know it's an area where we have to improve.
That's why we started a fully set of examples that will be: 1. part of the Karaf distribution 2. used in the itests to verify the behavior is correct. You can find the WIP on the example here: https://github.com/apache/karaf/pull/484 I'm still polishing/cleaning/adding examples but the idea is to provide a large set of turnkey samples users can start with. Please, keep me posted if you want to see additional examples for the first inclusion. Thanks ! Regards JB On 05/16/2018 10:25 PM, Alex Soto wrote: > 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 <http://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 <tim.w...@paremus.com >> <mailto:tim.w...@paremus.com>> 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 >> >> 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 <alex.s...@envieta.com >> <mailto:alex.s...@envieta.com>> 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 <tim.w...@paremus.com >>>> <mailto:tim.w...@paremus.com>> 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é <j...@nanthrax.net >>>>> <mailto:j...@nanthrax.net>> 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é <j...@nanthrax.net >>>>>>> <mailto:j...@nanthrax.net> <mailto:j...@nanthrax.net>> 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 >>>>>>>> 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"; >>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>>>>>>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence >>>>>>>> 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"; >>>>>>>> xmlns:jpa="http://aries.apache.org/xmlns/jpa/v2.0.0"; >>>>>>>> xmlns:tx="http://aries.apache.org/xmlns/transactions/v2.0.0"; >>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>>>>>>> xsi:schemaLocation="http://www.osgi.org/xmlns/blueprint/v1.0.0 >>>>>>>> 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 >>> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
