Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Best method for maintaining a session ID across multiple threads

by markdibley (Acolyte)
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 (Priest) 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 exploiting the Monastery: (5)
As of 2014-07-30 22:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (241 votes), past polls