In the newest code I removed support for transactions and currently rely
on aries transaction for that.
If you use <tx:transaction method="*" value="Required" /> in your bean
then it should work.
The annotation based transactions that aries transaction also provide do
not work for me. Unfortunately defined by aries transaction blueprint is
also not very usable
as you can not set it per class but only per method.
I originally planned to work on aries transaction to better support
annotation based transactions. Unfortuantely the code is quite tailored
for xml described transactions. As the annotations are also not great I
gave up on this for now.
So I propose to write a new module that only covers annotation based
transactions and also uses different annotations. Now the question is if
we should define another set of annotations or just use the jta 1.2
annotations. These are nice but currently do not work in karaf.
Upgrading to these is quite a lot of work. So I tend to wait with this
part until karaf supports the jta 1.2 annotations.
Another possibility would be to define our own set of annotations that
are similar to jhe jta 1.2 ones and make sure the new transaction module
is working with these but then wait for a release until jta 1.2 works in
karaf and switch before the release. This way we would avoid another set
of custom annotations and can still already test.
WDYT?
Christian
On 15.04.2015 12:21, Giuseppe Gerla wrote:
Hi Christian
I'd like to know if you make some progress about jpa-experiments and
transaction.
On my fork I create 2 bundles to make integration test and give you some
example of my use cases.
1. jpa-container-testbundle is equivalent of yours jpa-blueprint-example,
but I add some code for caching.
2. jpa-container-itest start karaf 2.4.1 environment and launch following
tests:
- TaskServiceImplTest.testPersistence is the same of yours but
without transaction management by code. This test fail because there is no
transaction manager active
- CarServiceImplTest.testCache check that the service is able to
create a cache. This test pass. If you see the code the getColours method
use init method in "lazy fetch" mode. If you try to use init method by
blueprint file to initialize the bean you have an exception because the
EmSupplier is not ready.
- CarServiceImplTest.testDatabaseInitializationQuery check that
properties are passed to EMF correctly. This test pass.
- CarServiceImplTest.testAddQuery check that is possible to insert
into db. This test fail because there is no transaction manager active
regards
Giuseppe
2015-04-10 18:09 GMT+02:00 Giuseppe Gerla <giuseppe.ge...@gmail.com>:
Hi Christian
I pushed on my fork 2 bundles to test jpa-experiments in an integrated
environment.
I create to test classes.
The first class is for non JTA (LOCL_RESOURCE) transaction that works
using .begin(), .commit() by code.
The second one is thinked to test JTA transaction. This test doesn't work
because it is based on @Transaction annotation, but there is no transaction
active.
I have a question for you. Using Pax-exam and Junit to do the test, how
can I enable the transaction support? I have no xml file...
regards
Giuseppe
2015-04-10 14:49 GMT+02:00 Giuseppe Gerla <giuseppe.ge...@gmail.com>:
Sorry, for my misunderstanding.
Yesterday I saws rows in table but probably they were entered from the
first version of software that had transactions triggered by xml.
With annotation, it seems that insert work fine but there are no commit
on the database. So I have no new rows in table.
I'd like to create (and I'm working on this topic) a bundle like
jpa-container-itest to do integration test of jpa-experiments.
I hope to commit a first draft of this bundle on my fork this evening.
Regards
Giuseppe
2015-04-10 0:17 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
Interesting. So you got the annotation based transactions working with
aries transaction blueprint?
Can you post your examples somewhere?
I would also be interested in the necessary changes in your cache. Maybe
we can also avoid that this is has to be done.
Christian
Am 09.04.2015 um 19:18 schrieb Giuseppe Gerla:
Hi Christian
good work!
I make several test today and all works fine also with transaction. I
use
your example to inject EmSupplier in my service and use @Transaction
annotation on methods that need it.
I find only one restriction. In my previous service implementation I
create
an internal cache during the bean instantiation. This is a problem
because
the EmSupplier is created after during the configuration phase. So I
changed my cache in a lazy cache and all works fine.
I hope during next days to go in detail of your examples.
If you need more help to develop other feature let me know.
N.B. I cannot test closure example because I don't use Java 8
Regards
Giuseppe
2015-04-09 14:46 GMT+02:00 Christian Schneider <ch...@die-schneider.net
:
Sorry it took a little longer. I have now committed my changes.
In fact I removed the check in the BeanProcessor and do it now inside
the
interceptor.
Apart from that I worked on making the jpa code compatible to aries
transaction and making blueprint-jpa independent of jta.
The reason for this is that JTA can be used independently from jpa so
it
makes sense to not mix both. For example we should be able to run JMS
and JPA in the same transaction. This would not work if we tie
transactions too much to jpa.
While trying to integrate with aries transaction blueprint I found some
problems:
- annotation based transactions are implemented but do not work. I
think
this is a bug in aries. The beanprocessor does not seem to be active.
- The aries @Transaction annotation is defined in a very unfortunate
way.
It only applies to methods. In many cases you would simply want to
annotate
a class with it.
Unfortunately I defined the copied transactions differently so they
also
applied to classes. So there was a conflict between the two. I now
completely removed the transaction annotation from the jpa-experiments
code. If we want to use annotation based transactions we will have to
use
different annotations anyway. I deferred this part for now.
Apart from that the xml declared transactions from aries transaction
blueprint now work nicely together with the new blueprint-jpa module.
The
example is defined this way now.
For the closure based example I introduced a new TransactionType enum
to
avoid using the aries one.
So both examples should now work again.
I also found that I forgot to implement the @PersistenceUnit support.
This
is one possible next enhancement.
For transaction support I wonder if we can reuse aries transaction
blueprint. I am not sure to be honest. It is tailored a lot towards xml
based annotations with * based filters and such. I would be in favour
of
dropping xml support completely for jpa and transactions and only have
annotations in the new code. Not sure if the community agrees though.
Christian
On 08.04.2015 22:24, Giuseppe Gerla wrote:
Yes, I verified that the problem is that the TxBeanProcessor check the
transaction type in the following code
Interceptor interceptor = (getTransactionType(supplierProxy) ==
PersistenceUnitTransactionType.JTA) ?
new XaTxInterceptorImpl(tm, supplierProxy) : new
ResourceLocalTransactionalInterceptor(supplierProxy);
cdr.registerInterceptorWithComponent(beanData, interceptor);
Did you remove this part?
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
