The whole reason for having an instance per thread is so that there won't be
shared state between the instances but there can be resources that are
reused for each Exchange that passes through the bean. There are/could be
many resources that I want to have an instance per thread. For example, one
of my beans is using the JVM's built-in SAX parser which doesn't allow its
parse() method to be called concurrently by multiple threads I don't want to
create a new parser and handler instance for every Exchange. Maybe I have a
custom persistor and I want to reuse JDBC connections. I might have each
instance hold on to a pre-initialized rules engine context so, as each
Exchange comes through, it can inject a few values, fire the rules and
return the results. Hopefully, you get the idea -- there are some resources
that are expensive to instantiate for various reasons.
Of course, I could use pools, ThreadLocal variables, etc., but it makes
coding the beans much simpler if, instead of having to code each single
instance to be multi-threaded, I can create an instance per thread. The
instances never know about each other or interact with each other. They just
run isolated in their own little space. They can preallocate resources that
might be expensive and then I can focus my attention on the points where
things do need to interact.
The point of my original question was just to ask if there was a way to tell
camel to create an instance per thread. I'm guessing there isn't and I can
kinda understand why because it is, in essence, creating a separate pipeline
for each thread. Maybe that is the way to do it in camel -- create my route
multiple times on the same endpoint.
On Fri, Aug 13, 2010 at 1:53 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> On Fri, Aug 13, 2010 at 2:26 AM, Ron Smith <ronsmit...@gmail.com> wrote:
> > I don't really want a new bean every time it is called. I just want one
> for
> > each thread.
>
> Why do you want to share state on the bean?
> You can easily code a method which is thread safe by not using any
> shared objects.
>
> And what's there really to share, between the current Exchange, and
> whatever the next Exchange is gonna be?
>
>
>
> >
> > On Thu, Aug 12, 2010 at 1:22 PM, Claus Ibsen <claus.ib...@gmail.com>
> wrote:
> >
> >> On Thu, Aug 12, 2010 at 7:19 PM, Ron Smith <ronsmit...@gmail.com>
> wrote:
> >> > I have created a route like this:
> >> >
> >> > from("tibco:queue:myqueue")
> >> > .threads(10)
> >> > .bean(StepOne.class, "handleMessage")
> >> > .bean(StepTwo.class, "handleMessage")
> >> >
> >> >
> >> > I had been testing my app without the threads(). After adding the
> >> threads()
> >> > I was surprised to find that it still only creates one instance of
> >> StepOne
> >> > and StepTwo and has all ten threads use those single instances. There
> is
> >> > probably something in the docs somewhere that says that is how it
> works
> >> but
> >> > I must have missed it. I was surprised because I prefer to use
> separate
> >> > instance of classes for each thread so I don't have to mess around
> with
> >> > ThreadLocal, etc. and, of course, everyone thinks the same way as me
> :-)
> >> >
> >> > Is there an easy way to get camel to create separate instances for
> each
> >> > thread?
> >> >
> >>
> >> You can use Spring and have it use prototype scoped for the bean
> >>
> >> Or just use a Processor and new the bean yourself and invoke the method.
> >>
> >>
> >> --
> >> Claus Ibsen
> >> Apache Camel Committer
> >>
> >> Author of Camel in Action: http://www.manning.com/ibsen/
> >> Open Source Integration: http://fusesource.com
> >> Blog: http://davsclaus.blogspot.com/
> >> Twitter: http://twitter.com/davsclaus
> >>
> >
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
