Allright, I am trying to follow the EnRoute tutorial.
I am getting this error:
Any idea (time frame) when this will move from SNAPSHOT dependencies?
It is highly unlikely that you’ll hit the same issues. The transaction control resource provider uses the DataSourceFactory directly to create a DataSource (either progamatically using a factory service or via config admin) that enlists itself in the ongoing transaction. This means that the answer to your question is “with Transaction Control you don’t have to do that because it does it automatically”
If you want to use XA transactions then the only requirement is that the DataSourceFactory can produce an XADataSource, otherwise it just uses the standard JDBC API to commit/rollback. If your DataSourceFactory doesn’t support XA then use the local resource provider implementation.
Best Regards,
Tim Sent from my iPhone 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.
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.
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 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 = "" class="">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:
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.
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 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
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]> 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]>> 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
|
