myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pieter Martin <pieter.mar...@gmail.com>
Subject Re: Conversations
Date Fri, 01 Jul 2011 20:26:14 GMT
Hi,

I just noticed for every request the conversation scoped producer is 
called. And the disposer not. I am expecting the producer only to be 
called once the conversation has timed out or been closed.

Is my understanding here correct?

Thanks
Pieter

On 01/07/2011 22:14, Pieter Martin wrote:
> Hi, looks like it worked.
>
> I can now inject a conversation scoped db instance into the faces 
> listener  set the threadvar and start the transaction.
>
> To clarify, is codi now starting a conversation before calling the 
> beforeRequest observer?
>
> Many thanks
> Pieter
>
>
> On 01/07/2011 20:09, Gerhard Petracek wrote:
>> hi pieter,
>>
>> you can try to patch codi with [1] (attention: it wouldn't work in
>> combination with view-access scoped beans).
>> if it works, we will include it in codi.
>> information about building codi is available at [2].
>> an alternative would be to produce a proxy instead of the real 
>> instance and
>> start the transaction lazily in the proxy before methods are invoked 
>> which
>> should be executed within the transaction.
>>
>> regards,
>> gerhard
>>
>> [1] http://people.apache.org/~gpetracek/myfaces/codi/20110701_01.patch
>> [2] https://cwiki.apache.org/confluence/display/EXTCDI/Building+CODI
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>>
>> 2011/7/1 Pieter Martin<pieter.martin@gmail.com>
>>
>>> Hi,
>>>
>>> Currently I have gotten the following to work, using only request 
>>> scoped db
>>> instance and backing beans.
>>>
>>> public class FacesListener {
>>>     @Inject
>>>     NakedGraph db;
>>>     @Inject
>>>     Logger logger;
>>>
>>>     public void beforeFacesRequest(@Observes @BeforeFacesRequest
>>> FacesContext ctx) {
>>>         logger.fine("**beforeFacesRequest, setting db and starting
>>> transaction");
>>>         GraphDb.setDb(db);
>>>         db.startTransaction();
>>>     }
>>>
>>>     public void afterFacesRequest(@Observes @AfterFacesRequest 
>>> FacesContext
>>> ctx) {
>>>         logger.fine("**afterFacesRequest, stopping transaction and 
>>> removing
>>> db");
>>>         db.stopTransaction(Conclusion.**SUCCESS);
>>>         GraphDb.remove();
>>>     }
>>>
>>> }
>>>
>>> GraphDb is a threadvar.
>>>
>>> I am hoping to do something similar but for a ConversationScoped db
>>> instance and backing beans. However the conversation is not active 
>>> during
>>> beforeFacesRequest.
>>>
>>> The idea is to have a conversation scoped producer for db instance. 
>>> With a
>>> corresponding @Disposal method to ensure that the db instance is closed
>>> properly. For every request made from jsf before jsf touches any 
>>> beans I
>>> need to set the db instance on the threadvar and start a transaction.
>>>
>>> The above code does not work as the conversation is not yet active 
>>> during
>>> beforeFacesRequest.
>>>
>>> When I go to a particular page, with a conversation scoped backing 
>>> bean,
>>> the backing bean will make entities available, loaded from the 
>>> conversation
>>> scoped db instance to view/edit on the page. Then on updating a 
>>> particular
>>> entity (backingBean.update) , seeing as jsf directly access the 
>>> entity and
>>> sets the fields the db instance needs to have been set on a 
>>> threadvar before
>>> jsf accesses the entity.
>>>
>>> I am looking for a listener of sorts to set the threadvar and start the
>>> transaction before jsf touches any beans but after the conversation is
>>> active.
>>>
>>> Hope it makes some sense.
>>> Thanks
>>> Pieter
>>>
>>>
>>>
>>> On 01/07/2011 09:15, Gerhard Petracek wrote:
>>>
>>>> hi pieter,
>>>>
>>>> please provide a bit more details. esp. the first phase of the jsf
>>>> request lifecycle which has to access this instance and how you would
>>>> like to access it.
>>>>
>>>> codi tries to restore the window-id as early as possible. the first
>>>> attempt is before the restore-view phase. if it isn't possible there,
>>>> codi restores it after the restore-view phase.
>>>>
>>>> conversation scoped beans can be accessed as soon as there is a 
>>>> window-id.
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>> 2011/6/30, Pieter Martin<pieter.martin@gmail.com**>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have the following requirement and wondering how to implement it 
>>>>> with
>>>>> codi.
>>>>>
>>>>> We want to use conversations and have a database instance that is
>>>>> conversation scoped. However for every request that we need to put 
>>>>> the
>>>>> conversation scoped database instance in a threadvar where domain
>>>>> entities can access it later. We are using a graph db and the domain
>>>>> entities uses the db instance to add vertexes and edges.
>>>>>
>>>>> For request scoped use cases it is easy to set the threadvar when
>>>>> observing the @BeforeFacesRequest event and to clear the threadvar on
>>>>> the @AfterFacesRequest.
>>>>>
>>>>> However this does not work for conversation scoped use cases as the
>>>>> conversation context is not yet active.
>>>>>
>>>>> Is there a suggested way for me to achieve this?
>>>>>
>>>>> Thanks
>>>>> Pieter
>>>>>
>>>>>
>


Mime
View raw message