Yeah, that could work. It's just that it necessarily adds complexity for users who don't need it.
The erlang equivalent of ThreadLocal is the process dictionary. --David On 02/07/2011 01:44 PM, Kenny MacDermid wrote: > Yes. I'm looking to have a service that requires authentication before > running other commands, and stores state between these commands. I've done > this in Java previously using a ThreadLocal client object on the service. > > On Mon, Feb 7, 2011 at 4:55 PM, David Reiss <[email protected]> wrote: > >> Oh, do you mean to only track state within a given connection? >> >> On 02/07/2011 12:13 PM, Kenny MacDermid wrote: >>> Thanks for the reply David, >>> >>> I could do state tracking using ETS, but I'm not sure how providing state >>> tracking would require processing the requests serially. >>> >>> The thrift_processor is already in it's own process. So you should be >> able >>> to have thrift_processor:loop(State0, ClientState0), and passed the state >>> along to thrift_processor:handle_function(State0, ClientState0), call >>> Handler:handle_function(Function, Params, ClientState0), and expected >> back >>> {Result, ClientState1}. >>> >>> Do you see any reason why this wouldn't work? I'd have to modify the >>> functions to take their state, and return it properly in handle_function, >>> but that doesn't sound too difficult. >>> >>> Kenny >>> >>> On Mon, Feb 7, 2011 at 1:48 PM, David Reiss <[email protected]> wrote: >>> >>>> You can use ETS. Doing state tracking the way a gen_server does would >>>> require processing requests serially, which is often unacceptable. >>>> >>>> --David >>>> >>>> On 02/05/2011 05:52 PM, Kenny MacDermid wrote: >>>>> Hello, >>>>> >>>>> Is there a way to track client state in the erlang thrift service. >>>>> >>>>> Current it seems the thrift processor calls Handler:handle_function >> with >>>> the >>>>> function, and parameters, but no state. >>>>> >>>>> Am I missing something? >>>>> >>>>> Thanks, >>>>> >>>>> Kenny >>>>> >>>> >>> >> >
