Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Best method for maintaining a session ID across multiple threads

by markdibley (Sexton)
on Jul 10, 2013 at 18:00 UTC ( #1043517=perlquestion: print w/ replies, xml ) Need Help??
markdibley has asked for the wisdom of the Perl Monks concerning the following question:

Hello

I need to maintain a sessionID that I receive from SalesForce when I login. The sessionID lasts for 15 minutes and then has to be renewed with a new login. However, I have multiple threads who all need to update SalesForce and if each of them login the login will cancel any current active sessionID.

I think this means that the best way to manage this is to either have a single thread responsible for issuing the current valid sessionID and renewing the sessionID when it becomes stale OR get each thread to read the sessionID from a file, test the date of the file to see if the sessionID is most likely to be stale, remove the file and generate a new one.

The problem I have with solution 1 is that I don't know how to get 2 threads to talk to each other. With solution 2 I am unhappy with the possibility that a thread can pick up a valid sessionID and then 1 second later another thread thinks it is going to be stale and resets it resulting in retries or complicated pausing rules.

I am sure this has been handled before, but my searches aren't being very productive. Is there a standard way of dealing with this problem? Or even better yet, a perl module that can handle it?

Thanks

Comment on Best method for maintaining a session ID across multiple threads
Re: Best method for maintaining a session ID across multiple threads
by BrowserUk (Pope) on Jul 10, 2013 at 18:36 UTC
    The problem I have with solution 1 is that I don't know how to get 2 threads to talk to each other.

    If the "threads" in question are these threads, then have you not encountered threads::shared?

    If not, you'll need to specify/clarify your meaning of "threads".


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Hi, thanks for the reply

      I realised last night that I had missed out a couple of key factors to my problem. The first is that each "thread" is actually a queued job on a Gridengine cluster so each "thread" isn't forked from the program that does the logging in and also the cluster is across multiple servers which have a shared disk space and network but obviously don't have access to each others' processes.

      I guess I am using the term thread incorrectly

      So after more thought about it I am going to investigate writing something that can serve the sessionID to "processes" via a port. And when it comes to renewing the sessionID to perhaps look for, or enforce a 10 second window to ensure the last "customer" has time to finish it's connection.

      Unless, of course, there is a better way to do it.

        I guess I am using the term thread incorrectly

        The generic term for a single instance in a cluster is 'node'.

        So after more thought about it I am going to investigate writing something that can serve the sessionID to "processes" via a port.

        Clustering software always has some form of message passing API that allows the processes to communicate.

        A quick google suggests that GridEngine supports OpenMPI. You shouldn't need to be inventing a solution for this, just read the docs.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Best method for maintaining a session ID across multiple threads
by Gangabass (Vicar) on Jul 11, 2013 at 03:32 UTC
    If you create your threads AFTER login when each thread will be logged in.
    my $mech = WWW::Mechanize->new(); $mech->submit_form( with_fields => { login => "your_login", password => "your_password", }, ); my @threads = map { threads->create( \&create_thread, $_ ) } ( 1 .. $config->{number_of_threads} );

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1043517]
Approved by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2015-07-04 15:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (60 votes), past polls