[saga-rg] persistent session management?

[Thilo Kielmann]

[I have put this back to the list. -- Thilo]


On Fri, Jul 29, 2005 at 01:11:04PM +0200, Andre Merzky wrote:
> > As I see it, we have 2 different things:
> > 
> > 1. session handles
> >    they are objects (data structures) within an application.
> > 
> > 2. tasks
> >    they have some state stored at the job submission service/mechanism,
> >    at least while they are active and running
> > 
> > Andre's question is about associating a task to a session handle.
> > IMHO, this should alway be possible (e.g., create a session handle and
> > assign it a task).
> 
> To clearify that point: every task WILL be associated to a
> session handle.  Always.
> 
> Question is, if that association can survive the
> lifetime/runtime of a application instance.  And if that is
> necessary/wanted.

My guess would be that NO. There should be an OPTION (default) to 
associate a task with a session handle. You can see from your example
that a mandatory/permanent association is not always possible.

> > > An "interesting" problem might be to find back an old job within the 
> > job submission machanism. For this purpose, two options might be
> > possible:
> > 
> > 1. the application stores some task identifier "somewhere"
> > 2. the job submission machanism allows to retrieve a list of all
> >    tasks, and the application (or an adaptor?) can match te right job
> >    based on the set of given properties...
> 
> 3. the job submission machanism allows to retrieve a list of
>    all tasks which the 'user' has access rights to, even if
>    they have not been created by a SAGA application.
> 
> I am afraid though that we can mandate neither of these
> options: 1 needs persistent storage, which might not be
> available/accessible.  2 and 3 need support for task
> listing on server side, which is not always given AFAIK.

What should be mandated is an operation to associate a task to a
session handle, based on some properties. The implementation (options
1, 2, 3, or even other) should go into the engine/adaptor implementation.
In some cases, this association may just fail, tough luck if there is
no implementation available under certain circumstances...


Thilo
-- 
Thilo Kielmann                                 http://www.cs.vu.nl/~kielmann/