Good to know, and thanks for the help David. I think I'll use ETS (keyed
with the pid) or the process dictionary for now and consider coming back to
the issue later.

I suspect there's a way to handle both situations for users, maybe with an
option ({stateful, }?). If I find time to get it working I'll send along a
patch.

Kenny

On Mon, Feb 7, 2011 at 5:52 PM, David Reiss <[email protected]> wrote:

> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>

Reply via email to