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 14:07:17 GMT
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