karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: MariaDB/JPA Transaction rollback not working
Date Fri, 18 May 2018 16:46:52 GMT
4.2.1-SNAPSHOT already updated to DS 1.4 (SCR 2.1.0) (ready on one of my 
branch).

Regards
JB

On 18/05/2018 17:50, Alex Soto wrote:
> Great, I solved the Eclipse problem.  Thanks.
> 
> Yes, Karaf provides DS 1.3,  but no DS 1.4 out off the box.
> Maybe this is available from Aries?
> 
> Best regards,
> Alex soto
> 
> 
> 
> 
>> On May 18, 2018, at 11:18 AM, Tim Ward <tim.ward@paremus.com 
>> <mailto:tim.ward@paremus.com>> wrote:
>>
>> Hi,
>>
>> Answers inline:
>>
>> Sent from my iPhone
>>
>> On 18 May 2018, at 16:55, Alex Soto <alex.soto@envieta.com 
>> <mailto:alex.soto@envieta.com>> wrote:
>>
>>> Thank you Tim for the very detailed explanation.
>>> There are  two problems I don’t know how to resolve:
>>>
>>> 1- BND generates this for my bundle:
>>>
>>> Require-Capability: 
>>>  osgi.extender;filter:="(&(osgi.extender=osgi.component)(version>=1.3.0)(!(version>=2.0.0)))”
>>>
>>> This is because I use the @Component and @Reference annotations. 
>>>  This is strange, since I should be using OSGi R7, so I am not sure 
>>> why it is saying 1.3.0.  Now when try to run in Karaf, even though I 
>>> am installing/scr/feature, it fails with unresolved requirement.
>>
>> So in the absence of information to the contrary this requirement is 
>> added based on your usage of Declarative Services features. If you use 
>> DS 1.3 features then DS 1.3 will be required.
>>
>> Since R7 added the bundle requirement annotations the @Component 
>> annotation has been annotated to require DS at the current spec 
>> version (this gives a more consistent behaviour than bnd’s 
>> heuristics). At a guess you are picking up a 1.3 requirement because 
>> you have the 1.3 annotations ahead of the 1.4 annotations on your 
>> classpath, but it could be triggered by other things too. On the other 
>> hand this isn’t actually a problem as the requirement is still 
>> satisfied by DS 1.4 and both versions will work for you at runtime.
>>
>> The Karaf scr feature really should be providing SCR 1.3 (which is 
>> required by the spec to provide the extender capability. That has been 
>> the current version of the spec for three years, and has been provided 
>> by Felix for at least 6 releases. I’d be pretty shocked if DS 1.3 
>> wasn’t supported. You may need help from a more Karaf focussed person 
>> to confirm this.
>>
>>>
>>> Since I could not find OSGi R7 in public Maven Repos, I followed 
>>> EnRoute depending on:
>>>       <dependency>
>>>         <groupId>org.osgi.enroute</groupId>
>>>         <artifactId>osgi-api</artifactId>
>>>         <version>7.0.0-SNAPSHOT</version>
>>>         <type>pom</type>
>>>         <scope>provided</scope>
>>>       </dependency>
>>>       <dependency>
>>>         <groupId>org.osgi.enroute</groupId>
>>>         <artifactId>enterprise-api</artifactId>
>>>         <version>7.0.0-SNAPSHOT</version>
>>>         <type>pom</type>
>>>         <scope>provided</scope>
>>>       </dependency>
>>
>> There’s no problem with you using these. On the other hand the OSGi 
>> API aggregations you are looking for are:
>>
>> https://mvnrepository.com/artifact/org.osgi/osgi.core
>>
>> https://mvnrepository.com/artifact/org.osgi/osgi.cmpn
>>
>> You can also find the individual specs under the org.osgi group id if 
>> you want to use a smaller hammer :)
>>
>>>
>>> 2- This is minor, and I see it also in the EnRoute project. While the 
>>> Maven build succeeds, Eclipse BND plugin shows 2 errors:
>>>
>>>     The default package '.' is not permitted by the Import-Package
>>>     syntax. This can be caused by compile errors in Eclipse
>>>     because Eclipse creates valid class files regardless of compile
>>>     errors. The following package(s) import from the default
>>>     package [org.enquery.encryptedquery.responder.data.service.impl]
>>>     (biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)pom.xml/encryptedquery-responder-dataline
>>>     0Maven Build Participant Problem 
>>>
>>>
>>>     The project was not built since its build path is incomplete.
>>>     Cannot find the class file for javax.persistence.EntityManager.
>>>     Fix the build path then try building this
>>>     projectencryptedquery-responder-dataUnknownJava Problem
>>>
>>>
>>
>> As the message suggests, this usually occurs when Eclipse has build 
>> errors for the project. Specifically in this case you seem to be 
>> building against a project which exposes the EntityManager interface 
>> somehow, but you don’t have the JPA API in your compile dependencies 
>> (normally these would come come in transitively from the project you 
>> depend on).
>>
>> I hope this helps,
>>
>> Tim
>>
>>>
>>>
>>> Best regards,
>>> Alex soto
>>>
>>>
>>>
>>>
>>>> On May 18, 2018, at 5:23 AM, Tim Ward <tim.ward@paremus.com 
>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>
>>>> Hi Alex,
>>>>
>>>> The bundles you need are listed in the bndrun for the JPA version of 
>>>> the enRoute application, but as I think you’re using OpenJPA (rather 
>>>> than Hibernate) it may help to explain things in relation to the 
>>>> Transaction Control JPA integration test for OpenJPA. I’m sure that 
>>>> at least some of this will be stuff you already know, but I’m trying 
>>>> to make sure I give a compete explanation.
>>>>
>>>> This method defines some extra properties to add to the persistence 
>>>> unit. It references a couple of open bugs in OpenJPA which may or 
>>>> may not affect you. It also adds schema generation as OpenJPA does 
>>>> not support the standard properties from JPA 2.1 
>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L34
>>>>
>>>> This method defines the OpenJPA bundles and their immediate 
>>>> dependencies. 
>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/SimpleOpenJPA_2_4_1_Test.java#L48
>>>>
>>>> You then need:
>>>>
>>>> • Aries JPA 2.7.0 - this provides the OSGi JPA Service 1.1 RI (1.1 
>>>> features are needed by the Aries Tx Control JPA resource provider to 
>>>> support XA)
>>>>
>>>> • Aries Tx Control Service - either XA or local depending on whether 
>>>> you need XA Transaction support. For example 
>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L365
>>>>
>>>> • Aries Tx Control JPA resource provider - either XA or local 
>>>> depending on your needs. Note that you can’t use the XA provider 
>>>> with the local service, but you can use the local provider with the 
>>>> XA service (although this doesn’t make a lot of sense to do). For 
>>>> example 
>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L377
>>>>
>>>> • A JDBC Service implementation supporting your database driver. H2 
>>>> supports this natively (which is why it is used in many examples) 
>>>> but MariaDB does not. Therefore you will need to deploy PAX-JDBC’s 
>>>> support. See 
>>>> https://github.com/ops4j/org.ops4j.pax.jdbc/tree/master/pax-jdbc-mariadb
>>>>
>>>> You then have the option of either programmatically assembling your 
>>>> Resource Provider, or using configuration. Configuration is 
>>>> generally easier and is what I normally recommend. At that point you 
>>>> need to create a factory configuration for the relevant PID (it 
>>>> depends on whether you use the local or XA resource provider, see 
>>>> https://github.com/apache/aries-tx-control/blob/master/tx-control-providers/jpa/tx-control-jpa-itests/src/test/java/org/apache/aries/tx/control/itests/AbstractJPATransactionTest.java#L175)
>>>>
>>>> The necessary configuration properties are:
>>>>
>>>> • url - the JDBC URL for your database
>>>> • osgi.jdbc.driver.class - the database driver class name, in your 
>>>> case org.mariadb.jdbc.Driver
>>>> • osgi.unit.name - the name of your persistence unit
>>>>
>>>> The result of this configuration will be a JPAEntityManagerProvider 
>>>> service registered in the service registry (using your 
>>>> EntityManagerFactoryBuilder and the MariaDB DataSourceFactory). You 
>>>> can then Inject that service into your code and combine it with the 
>>>> TransactionControl service to make a thread safe EntityManager that 
>>>> you can use in all your requests (just like the enRoute example does).
>>>>
>>>> I hope this helps,
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 17 May 2018, at 22:46, Alex Soto <alex.soto@envieta.com 
>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>
>>>>> Thanks Tim,
>>>>>
>>>>> I was using branch R7, changed to master, it builds now.
>>>>>
>>>>> Now I have updated my project to OSGi 7 with Transaction Control, 
>>>>> how do I deploy to Karaf?
>>>>> i.e., what bundles/features do I need?
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Alex soto
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On May 17, 2018, at 2:08 PM, Tim Ward <tim.ward@paremus.com 
>>>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>>>
>>>>>> Hi Alex,
>>>>>>
>>>>>> Bnd 4.0.0 was only released last Sunday, but this should have been

>>>>>> changed yesterday in this commit 
>>>>>> https://github.com/osgi/osgi.enroute/commit/9f9857c3d317cd08a7aaf7327c1904676299f9ee to

>>>>>> make sure enRoute kept building.
>>>>>>
>>>>>> EnRoute is automatically pushed to the sonatype OSGi nexus 
>>>>>> repository, so is it possible that you’re running offline, or 
>>>>>> firewalled from the repo? You should be able to force snapshot 
>>>>>> updates from the Maven command line.
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 17 May 2018, at 18:26, Alex Soto <alex.soto@envieta.com 
>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>
>>>>>>> Allright,  I am trying to follow the EnRoute tutorial.
>>>>>>>
>>>>>>> I am getting this error:
>>>>>>>
>>>>>>> [ERROR] Plugin biz.aQute.bnd:bnd-maven-plugin:4.0.0-SNAPSHOT
or 
>>>>>>> one of its dependencies could not be resolved: Could not find

>>>>>>> artifact biz.aQute.bnd:bnd-maven-plugin:jar:4.0.0-SNAPSHOT in
Bnd 
>>>>>>> Snapshots (https://bndtools.ci.cloudbees.com/job/bnd.master/lastSuccessfulBuild/artifact/dist/bundles/)

>>>>>>> -> [Help 1]
>>>>>>>
>>>>>>>
>>>>>>> Any idea (time frame) when this will move from SNAPSHOT dependencies?
>>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Alex soto
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On May 17, 2018, at 11:08 AM, Tim Ward <tim.ward@paremus.com

>>>>>>>> <mailto:tim.ward@paremus.com>> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> On 17 May 2018, at 15:17, Alex Soto <alex.soto@envieta.com

>>>>>>>> <mailto:alex.soto@envieta.com>> wrote:
>>>>>>>>
>>>>>>>>> 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 <tim.ward@paremus.com

>>>>>>>>>> <mailto:tim.ward@paremus.com>> 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 <alex.soto@envieta.com

>>>>>>>>>> <mailto:alex.soto@envieta.com>> 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.ward@paremus.com

>>>>>>>>>>>> <mailto:tim.ward@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.soto@envieta.com

>>>>>>>>>>>> <mailto:alex.soto@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.ward@paremus.com <mailto:tim.ward@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é 
>>>>>>>>>>>>>>> <jb@nanthrax.net <mailto:jb@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é 
>>>>>>>>>>>>>>>>> <jb@nanthrax.net 
>>>>>>>>>>>>>>>>> <mailto:jb@nanthrax.net><mailto:jb@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
> 

Mime
View raw message