[Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

Like a scheduler within the webapp? this way i can have orchestra to keep
EntityManager round to do 
lazy loading of a huge object.

Thanks


-- 
View this message in context: http://www.nabble.com/-Orchestra--Does-Orchestra-work-with-non-web-client--tf4410349.html#a12581733
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

Thanks for the advices.  and yes, I dont pass entity between conversation
and threads.
I also dont pass runnable between thread either.  

I will try to come up with a small app if I ran into problem

Thanks

-D



Mario Ivankovits wrote:
> 
> Hi!
>> 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.
>>   
> It is so hard to tell without having a look at the code. If you could 
> sometimes setup a small app showing the problems it would be a lot easier.
> 
> 
> What you have outlined above sounds not that bad - having an LFA per 
> thread should fix any concurrency issues. You just have to keep in mind, 
> that if you pass entities between threads the entity is "detached" for 
> the other thread - or at least has a different EntityManager attached to 
> it. Passing entities between conversations (which in fact is what you 
> get with the "LFA per thread" scenario" should be avoided - but ok, this 
> depends on how to work with them.
> 
> 
> 
> Ciao,
> Mario
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-Orchestra--Does-Orchestra-work-with-non-web-client--tf4410349.html#a12685236
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [Orchestra] Does Orchestra work with non web client?

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> 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.
>   
It is so hard to tell without having a look at the code. If you could 
sometimes setup a small app showing the problems it would be a lot easier.

What you have outlined above sounds not that bad - having an LFA per 
thread should fix any concurrency issues. You just have to keep in mind, 
that if you pass entities between threads the entity is "detached" for 
the other thread - or at least has a different EntityManager attached to 
it. Passing entities between conversations (which in fact is what you 
get with the "LFA per thread" scenario" should be avoided - but ok, this 
depends on how to work with them.

Ciao,
Mario

Re: [Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

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.

Re: [Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

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#a12608390
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [Orchestra] Does Orchestra work with non web client?

[Mario Ivankovits <ma...@ops.co.at>]

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

Re: [Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

The work around to have scheduler's task to by pass the service bean and
invoke the
DAO beans directly with DAO's entity manager is manually injected by the
scheduler's task

I think I have a good use case thou.

-D


Dan Tran wrote:
> 
> well,  both of my webclient and scheduler call the same service bean, with
> the help of 
> orchestra, the web client can have objects lazy loaded.
> 
> However, after the scheduler retreive it pojo via the service bean, the
> pojo is put into 
> detached state and therefor I cannot load the rest when needed.
> 
> Please keep in mind, my schedule'task knows nothing about entity manager.
> 
> -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.
>> 
>> 
>> Is there any reason to use Orchestra for a non-request-based lifecycle?
>> I mean, once the scheduler triggers an event a new bean might be 
>> instantiated doing all the work and holding the entityManager until the 
>> process ends - should work pretty well with plain Spring I think.
>> 
>> Could you please provide some additional infos about what you would like 
>> to do.
>> 
>> Ciao,
>> Mario
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-Orchestra--Does-Orchestra-work-with-non-web-client--tf4410349.html#a12605914
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [Orchestra] Does Orchestra work with non web client?

[Dan Tran <da...@gmail.com>]

well,  both of my webclient and scheduler call the same service bean, with
the help of 
orchestra, the web client can have objects lazy loaded.

However, after the scheduler retreive it pojo via the service bean, the pojo
is put into 
detached state and therefor I cannot load the rest when needed.

Please keep in mind, my schedule'task knows nothing about entity manager.

-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.
> 
> 
> Is there any reason to use Orchestra for a non-request-based lifecycle?
> I mean, once the scheduler triggers an event a new bean might be 
> instantiated doing all the work and holding the entityManager until the 
> process ends - should work pretty well with plain Spring I think.
> 
> Could you please provide some additional infos about what you would like 
> to do.
> 
> Ciao,
> Mario
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-Orchestra--Does-Orchestra-work-with-non-web-client--tf4410349.html#a12582918
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [Orchestra] Does Orchestra work with non web client?

[Mario Ivankovits <ma...@ops.co.at>]

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.


Is there any reason to use Orchestra for a non-request-based lifecycle?
I mean, once the scheduler triggers an event a new bean might be 
instantiated doing all the work and holding the entityManager until the 
process ends - should work pretty well with plain Spring I think.

Could you please provide some additional infos about what you would like 
to do.

Ciao,
Mario