camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Gardner <>
Subject Re: Camel's @Consume on a @Transactional method
Date Wed, 04 Mar 2009 15:56:54 GMT
I didn't get a solution to using it the way I intended originally. I
may revisit this later to try to get a simple test case to submit.

I was using the annotations like:

 public Blarg doFoo(@Body Foo foo, @Header(name="foo") {

When it would try to invoke the method, it was complaining about
duplicate method signatures available - I wonder if it was because it
was somehow seeing both the transactional proxy and the unproxied
thing and being confused somehow, or if I was doing something wrong.

What I've done in the meantime is just made my bean implement
Processor and have the Process method call the previously-annotated
method. Calling the transactional processor via a bean: reference
works - it was the beanRef: methodName= part that I wasn't able to get
to work.

For now, this works for my intended case - which is to have my
transaction manager in spring be able to open up hibernate sessions
for my seda routes or other things that are not invoked with an
existing hibernate session (If I wasn't wanting to have multiple
threads processing the messages or spawned in my messages I could use
the direct: routes exclusively for some of what I am trying to do and
rely on the openSessionInView to keep a long-lived session open - but
given the ease of marking things @Transactional there's no real reason
for doing that)

It would be really cool if the @Transactional annotation could be used
to configure transactional endpoints across the JMS stuff and the
hibernate stuff - i.e. have it rollback db stuff and put the message
back in the queue if there is an unchecked exception.

So the short answer is, I'm not sure what the nature of the original
problem was - but my workaround is working currently. Hibernate,
@Transactional, Seda routes, and using Bean: (for beans that implement
processor) in a route definition all seem to work nicely. The beanRef:
for things using annotations on the methods mixed with @Consume
doesn't seem to work for me.


On Wed, Mar 4, 2009 at 7:00 AM, James Strachan <> wrote:
> Are you dependency injecting the bean using Spring? All Camel does is
> get spring to create the bean (along with whatever interceptors for
> transactions/security etc).
> 2009/2/26 Ryan Gardner <>:
>> I'm able to use a processor with @Transactional methods called from the DSL
>> via beanRef("fooBean", "fooTransactionalMethod") and things work just fine -
>> but trying to step a bit away from the DSL to using the annotations to drive
>> some of my routes.
>> I tried doing this:
>> @Consume(uri = "activemq:newIncident")
>> @Transactional(readOnly = false)
>> public void handleNewFoo(@Body Foo foo, @Headers Map<String,Object>
>> messageHeaders) {
>>        ...
>> }
>> and I get this exception:
>> Caused by: org.hibernate.HibernateException: No Hibernate Session bound to
>> thread, and configuration does not allow creation of non-transactional one
>> here
>>        at
>> org.springframework.orm.hibernate3.SpringSessionContext.currentSession(
>>        at
>> org.hibernate.impl.SessionFactoryImpl.getCurrentSession(
>>        at
>> com.digitalbridge.dbdocs.dao.impl.GenericDAOImpl.saveOrUpdate(
>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>        at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>>        at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>        at java.lang.reflect.Method.invoke(
>>        at
>>        at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(
>>        at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>>        at
>>        ... 21 more
>> (I'm pretty sure I have the annotation-based @Transactional stuff setup
>> correctly...)
>> Is there some other way to configure this to be both messagedriven and
>> transactional?
>> Ryan
> --
> James
> -------
> Open Source Integration

View raw message