Re^2: Best method for maintaining a session ID across multiple threads

[markdibley]

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.

[BrowserUk]

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.

[markdibley]

I completely agree - I never invent a solution when there is an alternative, which is why I was asking for advice about existing solutions to the problem of maintaining a session ID. But OpenMPI appears to be an overly engineered solution for my requirements. If I had a week to learn and implement I might consider it, but thank you very much for your help and your suggestions.

[Anonymous Monk]

Use something like CGI::Session or Apache::Session (neither of which require CGI nor Apache), or Data::UUID