2010/1/17 Willi Schönborn <[email protected]> > On 17/01/2010 20:18, Fred Faber wrote: > > Is just one thread handling all the behavior within a "call" scope? > > > Yes and after reading your answer i am pretty sure i mixed things up. It's > absolutely > correct to use a threadlocal, as long as my scope is as long as the threads > life or (in my > case) shorter. Ok, i actually dont need it, but how would you implement > a scope greater than the lifespan of a thread (and less then singleton)? > Just curious. >
Good to hear you've found a solution.
For your question, you would need a value that identifies the scope that can
be shared among different threads.
Consider the basic http session: with each request, the server is
identifying a unique attribute of the request that can be tied back to a
given session. This is used to lookup the (maybe persistent) session for
the request. In the same light, you can lookup a map of scoped objects
within your implementation of Scope. This map would be a static var, with
an expiration for each entry (or LRU eviction policy, etc). Each thread
that fields a request would have the session id set on a globally accessible
ThreadLocal var. The implementation of scope would then read this session
id, lookup in its map of scoped objects, and then be able to do its thing.
-Fred
>
> If so, you can use ThreadLocals to implement the scope, as long as you
> signal when a thread enters and leaves the scope:
>
> callScope.enter();
> try {
> ...do stuff;
> } finally {
> callScope.exit();
> }
>
>
> And in this example, you can use SimpleScope right out of the box.
>
> If you are dispatching to multiple threads within the duration of a
> "call" scope, then you'll need to have child threads inherit their parent's
> values. But that question is orthogonal to designing a smaller lifespan of
> a longer scope (such as RequestScope), and the example above should suffice.
>
>
>
> 2010/1/17 Willi Schönborn <[email protected]>
>
>> On 17/01/2010 19:43, [email protected] wrote:
>>
>>>
>>> On Jan 17, 6:10 am, Willi Schönborn<[email protected]>
>>> wrote:
>>>
>>>
>>>> we have a custom made framework here which has 4 scopes:
>>>> - Application
>>>> - HTTP Session
>>>> - HTTP Request
>>>> - Call
>>>>
>>>> Call is something that can happen multiple times during one request.
>>>> I dont think there is really a need to understand the semantic, anyways
>>>> the request is bound to a thread, so i can use a threadlocal to keep
>>>> track
>>>> of the current request, which itself has a reference to the current
>>>> session.
>>>> Any idea how i can keep track of the current call?
>>>>
>>>>
>>> Take a look at CustomScopes:
>>> http://code.google.com/p/google-guice/wiki/CustomScopes
>>>
>>>
>> I know about custom scopes, what i need is a hint/idea/whatever how to
>> implement
>> a scope that does not rely on a threadlocal. All non-singleton scopes i
>> know about, like
>> the request scope, the session scope or the example implementatio of
>> simple scope (see your link)
>> are all based on a threadlocal which itself only works when you use
>> threads. The problem is,
>> my custom scope (@CallScoped) is shorter than a request, so i cant use a
>> threadlocal.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "google-guice" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]<google-guice%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-guice?hl=en.
>>
>>
>>
>>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-guice" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-guice%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-guice?hl=en.
>
>
-- You received this message because you are subscribed to the Google Groups "google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
