I think Tim Peierls has a framework for this sort of thing... On Mon, Jan 18, 2010 at 6:31 AM, Fred Faber <[email protected]> wrote:
> > > 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]<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.
