it works!!
However I am also running to concurrentcy issue, most likely due to my
newbie knowledge about
orchestra conversation, let me sketch it out to see if you can give some
advice.
1. First i have a transactional service bean with one of its methods spins a
runnable to do some work.
The runnable, after complete the long work, calls the same service bean to
do the persistent
2. I also have a couple of JSF backing beans and a scheduler task which call
the same service bean as
stated in 1 to retreive the persisted data and then do the long work in
parallel, ofcourse these dont work on the same dataset.
So what is the correct conversation setting for for these bean?
Here is what have have in mind
1. have the JSF backing bean to have the same convesation name.
The service bean is singleton scope
2. have the runnable in its own conversation, the conversation ends when
the run method ends
I also have another instance of same service bean, with different name
in prototype mode.
3. The scheduler task in its own converstion scope, similar to 1
4. Use LocalFrameworkAdapter for each runnable and also in each scheduler
task.
any advice is greatly appreciated.
Thank you for all the good work.
-D
Dan Tran wrote:
>
>
> This is way too cool,
>
> Thanks
>
> -D
>
>
> Mario Ivankovits wrote:
>>
>> Hi!
>>>>>> Like a scheduler within the webapp? this way i can have orchestra to
>>>>>> keep
>>>>>> EntityManager round to do
>>>>>> lazy loading of a huge object.
>>>>>>
>>>>>>
>>>>> No, many of Orchestra's data-structures are kept in the session scope
>>>>> which is not available during a non http request.
>>>>>
>> After thinking about again it I realized that I wrote nonsense here.
>> In fact Orchestra WILL work in non servlet environments .... for
>> example, we startup a compatible environment for our junit tests.
>>
>> And it sould be simple - it is all about the FrameworkAdapter.
>> I've copied our mock class over to the core and now there is a
>> org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter
>> class which should help you to solve the problem.
>>
>> Use it with something like this:
>>
>> LocalFrameworkAdapter frameworkAdapter = new
>> LocalFrameworkAdapter();
>> frameworkAdapter.setApplicationContext(applicationContext); //
>> <= the Spring application context you have to gather from somewhere
>> FrameworkAdapter.setInstance(frameworkAdapter);
>>
>> Notice, FrameworkAdapter.setInstance is thread bound, so you'll have to
>> do this for each thread going to use Orchestra.
>> If you use a fresh frameworkAdapter per run or share it over multiple
>> runs is up to you, depending if you have conversations running longer
>> than one sheduler task, however, the LocalFrameworkAdapter is not thread
>> safe. If you need such a feature, just copy over the
>> LocalFrameworkAdapter and synchronized the maps, however (2), the entity
>> manager itself is not thread safe.
>>
>> I don't know how your sheduler works, but you also could configure this
>> FrameworkAdapter as prototype in Spring and get the ApplicationContext
>> injected ... automatically.
>>
>>
>> Ciao,
>> Mario
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/-Orchestra--Does-Orchestra-work-with-non-web-client--tf4410349.html#a12658639
Sent from the My Faces - Dev mailing list archive at Nabble.com.
