[seam-issues] [JBoss JIRA] Commented: (SEAMCRON-6) Can we use @RequestScoped for @Scheduled and @Asynchronous methods? How?

[Bernard Labno (JIRA)]

    [ https://issues.jboss.org/browse/SEAMCRON-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620221#comment-12620221 ] 

Bernard Labno commented on SEAMCRON-6:
--------------------------------------

Seam managed persistence context doesn't make sense at all in async methods. It may be substituted with @PersistenceContext as you need it only for method invocation.

However in Seam2 i've been using EntityHome's for business logic (and as DAO) so I also used them in async methods. However they were conversation scoped, so if we'd like to use EntityHome in seam3 then async methods would have to support conversation scope. The question is should business component be scoped to anything other then dependant or application scope?

> Can we use @RequestScoped for @Scheduled and @Asynchronous methods? How?
> ------------------------------------------------------------------------
>
>                 Key: SEAMCRON-6
>                 URL: https://issues.jboss.org/browse/SEAMCRON-6
>             Project: Seam Cron
>          Issue Type: Task
>            Reporter: Peter Royle
>            Assignee: Peter Royle
>             Fix For: 3.0.0.Alpha2
>
>
> This is one for investigation some time. It came up in this IRC chat:
> The weld reference document (page 34) states:
> The request and application scopes are also active:
> • during invocations of EJB remote methods,
> • during invocations of EJB asynchronous methods,
> • during EJB timeouts,
> • during message delivery to a message-driven bean,
> • during message delivery to a MessageListener, and
> • during web service invocations.
> So we should be able to support this, even if only for certain providers (ie: EJB)
> IRC Transcript:
> [11:10am] johnament: request scoped won't be active in a background thread.
> [11:10am] PeteRoyle: ah true cos it's threadlocal?
> [11:10am] johnament: which?
> [11:11am] PeteRoyle: request scoped implementation
> [11:11am] PeteRoyle: won't work in a background thread because the implementation of request scope uses threadlocal, is that right?
> [11:11am] johnament: its essentially an HTTP request
> [11:12am] PeteRoyle: right
> [11:12am] PeteRoyle: I think the use case is valid though, do you agree?
> [11:13am] johnament: its valid, but it breaks the CDI model, so to say
> [11:13am] johnament: because you want to make your contextual objects available outside of your context
> [11:14am] PeteRoyle: right yeah that makes sense
> [11:14am] PeteRoyle: the request might be over
> [11:14am] johnament: the only thing really available is going to be dependent or application scoped
> [11:15am] johnament: the bigger question - which request?
> [11:15am] PeteRoyle: well the one from which the @Asynch method was called - assuming we could hang onto it
> [11:15am] PeteRoyle: hang onto the request that is
> [11:16am] PeteRoyle: eg: a controller which @Injects a @RequestScoped Thing, then calls an @Asynchronous method
> [11:17am] johnament: the only way it would work is to make request scope extend through your @asynch process is over.
> [11:18am] PeteRoyle: The interceptor would have access to the correct @RequestScope. It would need to replicate it into the new thread. Would that be possible do you think?
> [11:18am] johnament: i don't know how plausible/possible that even is.
> [11:18am] PeteRoyle: yeah. I might leave that as something for investigation later. I'll JIRA it
> [11:18am] johnament: jms does this by transporting the event over JMS, but loses the context.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira