I will take a look at these examples. However, I think that if I cannot get a MariaDB DataSource that supports transactions, then it will still not work, right? If the examples use H2 database, I still may get different results when I change to MariaDB, and I will find myself in the same spot as of now.
So, the question remains about what is the correct way how to register a transaction aware MariaDB DataSource. Best regards, Alex soto > On May 17, 2018, at 1:46 AM, Tim Ward <[email protected]> wrote: > > The best place to start when looking for OSGi R7 examples is the enRoute > Project. It contains Maven Archetypes, examples and worked tutorials for > building applications using R7 specifications. > > https://enroute.osgi.org <https://enroute.osgi.org/Tutorial/> > > Most of the projects in use are just new versions of long established OSGi > implementations from Aries and Felix. The majority of them are already > released and in Maven Central. Those that are still in the process of > releasing (pretty much just the JAX-RS whiteboard) are available in the > Apache Snapshots repository. I am not aware of any implementations that > require R7 framework features, so all of them should run on Karaf. > > Best Regards, > > Tim > > Sent from my iPhone > > On 16 May 2018, at 22:25, Alex Soto <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[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 >>>> >>
