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

[Stefano Travelli (JIRA)]

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

Stefano Travelli commented on SEAMCRON-6:
-----------------------------------------

We was discussing something similar about seam-servlet at http://seamframework.org/Community/WebApplicationStartupEventAndRequestContet 

"no session, no conversation" makes perfectly sense for long running conversation, but in some common use cases a temporary conversation could be enough. With the current behaviour we build all our business components (DAO, etc) with the beloved seam managed persistence context only to discover that we cannot reuse them in @Scheduled, @Asynchronous, in Message Driven Bean and at application startup because the entityManager is conversation scoped. 

> 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