Throwing a RuntimeException from inside the transaction boundary that bubbles
across the transaction boundary. So in the example you had previously, you
could make the exception a RuntimeException and remove the try catch blocks
that should trigger a rollback.
You are still going to get the original exception rather than a
TransactionRollbackException this way. If you want a rollback exception you
could get access to the transaction (say via UserTransaction) and call
setRollbackOnly.
On 16 Nov 2010, at 14:08, Charles Moulliard wrote:
> How do you simulate an error to have a rollback in your code ?
>
> On 16/11/10 14:49, Valentin Mahrwald wrote:
>> Agreed :)
>>
>> The third trace essentially says your transaction is starting. But there is
>> no matching trace to say it commited :(
>> In error cases though you will get another trace entry, so by the looks all
>> your transactions succeed ?!
>>
>> On 16 Nov 2010, at 13:08, Charles Moulliard wrote:
>>
>>> BTW, I have enable tracing mode for the class org.apache.aries.transaction
>>> but the trace does not report begin and commit or rollback
>>>
>>> 14:05:42,952 | DEBUG | tenerContainer-1 | TxComponentMetaDataHelperImpl
>>> | on.TxComponentMetaDataHelperImpl 185 | 271 -
>>> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Getting the
>>> txAttribute for the component {0} and method {1}
>>> 14:05:42,952 | DEBUG | tenerContainer-1 | TxComponentMetaDataHelperImpl
>>> | on.TxComponentMetaDataHelperImpl 197 | 271 -
>>> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Return the
>>> txAttribute {0} for the component and method
>>> 14:05:42,953 | DEBUG | tenerContainer-1 | TxInterceptorImpl
>>> | es.transaction.TxInterceptorImpl 110 | 271 -
>>> org.apache.aries.transaction.blueprint - 0.2.0.incubating | Method: public
>>> void
>>> org.apache.camel.example.reportincident.dao.impl.IncidentDAOImpl.saveIncident(org.apache.camel.example.reportincident.model.Incident),
>>> has transaction strategy: REQUIRED
>>> 1
>>>
>>> This should be nice to have this info because for the moment we have no
>>> idea if the transaction occurs or not.
>>>
>>> On 16/11/10 13:44, Charles Moulliard wrote:
>>>> You are right. I made a mistake in my code to simulate an error + rollback
>>>>
>>>> On 16/11/10 12:21, Valentin Mahrwald wrote:
>>>>> I am a bit confused by the scenario. If I understand this correctly the
>>>>> saveIncident method throws an exception and catches it inside the method
>>>>> itself. So the transaction that spans around the saveIncident method
>>>>> would be unaffected ?!
>>>>>
>>>>> What are you trying to simulate?
>>>>>
>>>>> Just looking over it there is not a lot of trace. However,
>>>>> org.apache.aries.transaction.TxInterceptorImpl logs (at debug) when
>>>>> transactions start and if they fail.
>>>>>
>>>>> On 16 Nov 2010, at 10:37, Charles Moulliard wrote:
>>>>>
>>>>>> That does not work. In fact I'm not even sure that a transaction has
>>>>>> been initiated
>>>>>>
>>>>>> I have made the following modification
>>>>>>
>>>>>> 1) DAO
>>>>>>
>>>>>> <bean id="incidentDAO"
>>>>>>
>>>>>> class="org.apache.camel.example.reportincident.dao.impl.IncidentDAOImpl">
>>>>>> <!--<tx:transaction method="*" value="Required" /> -->
>>>>>> <jpa:context property="entityManager" unitname="ReportIncident" />
>>>>>> </bean>
>>>>>>
>>>>>> 2) Service
>>>>>>
>>>>>> <bean id="incidentService"
>>>>>> class="org.apache.camel.example.reportincident.service.impl.IncidentServiceImpl">
>>>>>>
>>>>>> <tx:transaction method="*" value="Required" />
>>>>>>
>>>>>> <property name="incidentDAO">
>>>>>> <reference
>>>>>> interface="org.apache.camel.example.reportincident.dao.IncidentDAO"/>
>>>>>> </property>
>>>>>>
>>>>>> </bean>
>>>>>>
>>>>>> 3) Simulation of an error
>>>>>>
>>>>>> public class IncidentServiceImpl implements IncidentService {
>>>>>>
>>>>>> private static final transient Log LOG =
>>>>>> LogFactory.getLog(IncidentServiceImpl.class);
>>>>>>
>>>>>> /** The incident dao. */
>>>>>> private IncidentDAO incidentDAO;
>>>>>>
>>>>>> public void saveIncident(Incident incident) {
>>>>>>
>>>>>> try {
>>>>>> getIncidentDAO().saveIncident(incident);
>>>>>> throw new Exception(">> Generate Error to simulate
>>>>>> RollBack");
>>>>>> } catch (RuntimeException e) {
>>>>>> e.printStackTrace();
>>>>>> } catch (Exception ex) {
>>>>>> ex.printStackTrace();
>>>>>> }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> Is there a way to trace in log the Aries Transaction ?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Charles
>>>>>>
>>>>>> On 16/11/10 10:49, Valentin Mahrwald wrote:
>>>>>>> On 16 Nov 2010, at 09:42, Charles Moulliard wrote:
>>>>>>>
>>>>>>>> There was a conflict with another ServiceMix bundle providing too jndi
>>>>>>>> context. I have remove it and restart my project. Everything works
>>>>>>>> fine.
>>>>>>>>
>>>>>>>> This is easier to configure compare to Spring + Hibernate stuffs on
>>>>>>>> OSGI. I will produce a tutorial with camel + aries + jpa + transaction
>>>>>>>> + wicket about that and show How Aries JPA/Transaction simplifies our
>>>>>>>> lives on OSGI platform.
>>>>>>>>
>>>>>>>> Question : In all the examples (Blog, AriesTrader), the transaction is
>>>>>>>> defined in the DAO layer (= layer containing the entityManager). Could
>>>>>>>> it be possible that I define the tx within the Service layer (in
>>>>>>>> charge to call the DAO) ?
>>>>>>> Yes, for all I know that should work. The JPA and Transaction
>>>>>>> extensions are entirely independent. The transaction extensions manages
>>>>>>> the transaction bound to the current thread while the JPA extension
>>>>>>> manages EntityManagers (and -Factories) that access
>>>>>>> the transaction currently active on the thread.
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Charles
>>>>>>>>
>>>>>>>> On 16/11/10 10:26, Alasdair Nottingham wrote:
>>>>>>>>> That is very odd. Something has not worked because the stack trace
>>>>>>>>> shows the InitialContextFactoryBuilder has not been registered.
>>>>>>>>>
>>>>>>>>> Could there be a timing issue? Perhaps the jndi bundle starts after
>>>>>>>>> your test. Certainly the jndi bundle has the highest id.
>>>>>>>>>
>>>>>>>>> Alasdair Nottingham
>>>>>>>>>
>>>>>>>>> On 16 Nov 2010, at 09:11, Charles Moulliard<[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yes. The Aries JNDI bundle is started
>>>>>>>>>>
>>>>>>>>>> [ 178] [Active ] [ ] [ ] [ 60] Apache Aries
>>>>>>>>>> JNDI Bundle (0.2.0.incubating)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 16/11/10 09:52, Alasdair Nottingham wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Have you deployed and started the jndi bundle?
>>>>>>>>>>>
>>>>>>>>>>> Alasdair
>>>>>>>>>>>
>>>>>>>>>>> On 16 Nov 2010, at 08:18, Charles Moulliard<[email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Based on the Blog example of Aries, I have created a small project
>>>>>>>>>>>> that I deploy on Fuse ESB (=Apache ServiceMix 4). The project
>>>>>>>>>>>> includes a DAO layer (=JPA), Service layer, Camel route (where a
>>>>>>>>>>>> bean calls my service layer).
>>>>>>>>>>>>
>>>>>>>>>>>> The following error is reported :
>>>>>>>>>>>>
>>>>>>>>>>>> Caused by: java.lang.RuntimeException: The DataSource
>>>>>>>>>>>> osgi:service/javax.sql.DataSource/(osgi.jndi.service.name=jdbc/reportincidentdb)
>>>>>>>>>>>> could not be used.
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getDs(DelayedLookupDataSource.java:47)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getConnection(DelayedLookupDataSource.java:60)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.openjpa.lib.jdbc.DelegatingDataSource.getConnection(DelegatingDataSource.java:137)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.openjpa.lib.jdbc.DecoratingDataSource.getConnection(DecoratingDataSource.java:112)
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.openjpa.jdbc.schema.DataSourceFactory.installDBDictionary(DataSourceFactory.java:239)
>>>>>>>>>>>> ... 100 more
>>>>>>>>>>>> Caused by: javax.naming.NoInitialContextException: Need to specify
>>>>>>>>>>>> class name in environment or system property, or as an applet
>>>>>>>>>>>> parameter, or in an application resource file:
>>>>>>>>>>>> java.naming.factory.initial
>>>>>>>>>>>> at
>>>>>>>>>>>> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645)
>>>>>>>>>>>> at
>>>>>>>>>>>> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)[:1.6.0_22]
>>>>>>>>>>>> at
>>>>>>>>>>>> javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325)[:1.6.0_22]
>>>>>>>>>>>> at
>>>>>>>>>>>> javax.naming.InitialContext.lookup(InitialContext.java:392)[:1.6.0_22]
>>>>>>>>>>>> at
>>>>>>>>>>>> org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getDs(DelayedLookupDataSource.java:43)
>>>>>>>>>>>>
>>>>>>>>>>>> Here is the bundle that I deploy to use Aries
>>>>>>>>>>>>
>>>>>>>>>>>> [ 7] [Active ] [Created ] [ ] [ 20] Apache Aries
>>>>>>>>>>>> Blueprint Bundle (0.2.0.incubating)
>>>>>>>>>>>> [ 49] [Active ] [ ] [ ] [ 60] Apache Aries
>>>>>>>>>>>> Transaction Manager (0.2.0.incubating)
>>>>>>>>>>>> [ 167] [Active ] [Created ] [ ] [ 60] Aries JPA
>>>>>>>>>>>> Container blueprint integration for Aries blueprint
>>>>>>>>>>>> (0.2.0.incubating)
>>>>>>>>>>>> [ 170] [Active ] [Created ] [ ] [ 60] Apache Aries
>>>>>>>>>>>> Transaction Blueprint (0.2.0.incubating)
>>>>>>>>>>>> [ 171] [Active ] [ ] [ ] [ 60] Aries JPA
>>>>>>>>>>>> Container (0.2.0.incubating)
>>>>>>>>>>>> [ 172] [Active ] [ ] [ ] [ 60] Apache Aries
>>>>>>>>>>>> Util (0.2.0.incubating)
>>>>>>>>>>>> [ 175] [Active ] [ ] [ ] [ 60] Aries JPA
>>>>>>>>>>>> Container Managed Contexts (0.2.0.incubating)
>>>>>>>>>>>> [ 178] [Active ] [ ] [ ] [ 60] Apache Aries
>>>>>>>>>>>> JNDI Bundle (0.2.0.incubating)
>>>>>>>>>>>>
>>>>>>>>>>>> [ 166] [Active ] [Created ] [ ] [ 60]
>>>>>>>>>>>> Reportincident :: Persistence JPA :: Aries (1.0.0.SNAPSHOT)
>>>>>>>>>>>> [ 176] [Active ] [Created ] [ ] [ 60]
>>>>>>>>>>>> Reportincident :: Service Bundle :: Aries (1.0.0.SNAPSHOT)
>>>>>>>>>>>>
>>>>>>>>>>>> What is the reason ? Is there a bundle that I miss to deploy ?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Charles M.
>>>>>>>>>>>> Apache Committer (Camel, Servicmix and Karaf)
