Jeff, A session is scope used to define a set of running jobs. Sessions have two effects. First, they enable the synchronize(ALL), wait(ANY), and control(ALL) methods. With the ANY/ALL parameters, those method operate on any/all jobs in the session. Second, the session also tends to bound job visibility. You cannot call wait() or synchronize() on a job that was not submitted during the same session as the wait() call. The same may apply to control() and getJobProgramStatus(), depending on the implementation. With SGE, it does apply. With the SGE 6.0u9 (coming soon) implementation of DRMAA, you have the ability to re-open a session that was previously exited. This is important when writing daemons. Otherwise, if your daemon crashes, you lose access to all the jobs that were previously submitted. The caveat is that any jobs that ended between exiting the session and reattaching to it will no longer be accessible. We've considered fixing that hole, but so far, the cure is worse than the disease. Daniel Jeff White wrote:

I have a daemon process that periodically submits jobs to SGE. I have a separate thread that uses Session.wait(JOBS_IDS_SESSION_ANY) to gather the JobInfo objects, for example to add to a completion queue. The session may be idle for long periods of time. Should I use a single Session for the entire duration of the application, for each submitted job, or something in between?

jeff