aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Fwd: Re: Prototype for a new aries jpa impl
Date Mon, 20 Apr 2015 15:49:56 GMT
I also thought about putting the transaction type into the properties of 
the EMF service.
This would avoid that we need to "probe" for the type. The problem is 
that this property is not specified by the jpa spec.
So I was a bit hesitant to do so. It might be a good option to avoid the 
problem though. So I agree to do it this way.

I just checked out your test bundle and itest. The hibernate variant 
seems to run fine. The eclipselink variant shows the exception with 
RollbackOnly in the testCache method. I wonder why they behavve 
differently.

Christian


On 19.04.2015 09:54, Giuseppe Gerla wrote:
> Hi Christian
> I checked code about exception raised during integration test in Karaf and
> I found an issue on transaction type retrieving method. Using magaed
> exception, eclipselink (but I think also hibernate) set transaction manager
> in rollback only state and this do fail the test.
> To avoid this behaviour I put the transaction type in the properties map of
> EntitiManagerFactory and then, when it is needed, I get it from the map.
>
> I also change integration tests to manage the same service and same
> functionality with several implementation (eclipselink and hibernate). Now
> we have an example of my use case.
>
> Before I open a pull request, I'd like to know wdyt.
>
>
>
> 2015-04-15 14:43 GMT+02:00 Giuseppe Gerla <giuseppe.gerla@gmail.com>:
>
>>  From my point of view, because we are working on a beta version of new
>> Aries JPA, the best way to proceed is to prepare a set of annotation
>> similar to JTA 1.2 and use it.
>> In this way we can complete our beta, test it and we are ready to delivery
>> the new Aries JPA when Karaf will be compliant with JTA 1.2.
>> If I can do something let me know.
>>
>> About your suggestion to use <tx:transaction method="*" value="Required"
>> /> in the bean definition, I try it but it didn't work. It seems that I
>> have to manually (by code) begin and commit the transaction.
>> Car test with eclipselink gives
>> javax.transaction.RollbackException: Transaction is marked for rollback
>>          at
>> org.apache.geronimo.transaction.manager.TransactionImpl.registerSynchronization(TransactionImpl.java:147)
>>          at
>> org.eclipse.persistence.transaction.JTATransactionController.registerSynchronization_impl(JTATransactionController.java:92)
>>          at
>> org.eclipse.persistence.transaction.AbstractTransactionController.bindToCurrentTransaction(AbstractTransactionController.java:134)
>>          at
>> org.eclipse.persistence.transaction.AbstractTransactionController.registerSynchronizationListener(AbstractTransactionController.java:431)
>>          at
>> org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerWithTransactionIfRequired(UnitOfWorkImpl.java:4431)
>>          at
>> org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper.registerIfRequired(JTATransactionWrapper.java:110)
>>          at
>> org.eclipse.persistence.internal.jpa.EntityManagerImpl.getActivePersistenceContext(EntityManagerImpl.java:1957)
>>          at
>> org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:863)
>>          at
>> org.eclipse.persistence.internal.jpa.QueryImpl.performPreQueryFlush(QueryImpl.java:963)
>>          at
>> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:207)
>>          at
>> org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:469)
>>          at
>> net.lr.jpa.itest.service.impl.CarServiceWithSupplierImpl.getCars(CarServiceWithSupplierImpl.java:34)
>> Task test with hibernate gives
>> java.lang.NullPointerException
>>          at
>> net.lr.txmanager.blueprint.JpaInterceptor.postCallWithException(JpaInterceptor.java:53)
>>          at
>> org.apache.aries.blueprint.proxy.Collaborator.postInvokeExceptionalReturn(Collaborator.java:136)
>>          at
>> org.apache.aries.blueprint.proxy.Collaborator.preInvoke(Collaborator.java:78)
>>          at Proxya4faffee_6ed9_4df4_990d_596565ea8a97.addTask(Unknown
>> Source)
>>
>>
>> this evening I try to debug the application. Have you any suggestion?
>>
>>
>>
>> 2015-04-15 14:20 GMT+02:00 Christian Schneider <chris@die-schneider.net>:
>>
>>> 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.gerla@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.gerla@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 <chris@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 <
>>>>>>>> chris@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
>>>
>>>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message