Typically what you would do is store the object you want to propagate in an
Exchange property, eg. just before a threads() DSL.
On the other side of the concurrency threshold, you would unwrap the object
back into its thread-bound structure from the Exchange property.
If you have a look at the fe
Right - I just found your code. The limitation you mention - async
processors, threads(), multicast() - is exactly what the approach I
describe is meant to overcome.
When a situation like that happens, i.e. a new thread takes over, it gets a
copy of the original exchange, and an ExchangeCreateEven
this is what I used to implement an @ExchangeScoped but it has several
limitation, in particular when breaking the flow with .threads() or
.multicast(). All is explained on
http://camel.apache.org/threading-model.html .
Using a camel interceptor would surely allow to pass the context through
the e
Just wanted to ping the thread in the hope someone will offer help.. I
think the answer may also be useful to people in other situations who
wonder how Camel works under the hood with regard to threads. Thanks!
On Mon, Aug 24, 2015 at 12:47 PM, Jan Zankowski
wrote:
> Hi,
>
> My goal is to implem
Hi,
My goal is to implement DB multitenancy in a Camel application using
Hibernate and Spring. For this, I need to implement the following Hibernate
interface, which gets called on each read/write to the DB.
public interface CurrentTenantIdentifierResolver {
public String resolveCurrentTenantId
