[saga-rg] persistent session management?

[Andre Merzky]

Quoting [Thilo Kielmann] (Jul 29 2005):
> 
> [I have put this back to the list. -- Thilo]

Oops


> 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.

Well, the SAGA spec as it stands says that every SAGA
object is associated with a session handle on creation time,
and also with security handles attached to the session
handle.  I think for the lifetime of an application that
makes perfect sense.

So removing that behaviour, and making that optional would
open a can of other issues.  So I think association of a
task to a session handle should NOT be optional, really.

Or did I misunderstand you?


> > > > 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...

So, what happens if that operation fails?  What certificate
etc. do I use to access task information, if the task is not
attached to a session handle and its security information?

Also, the operation of creating or finding the task involves
a session handle in the first place - why shouln't that be
reused?

I think we arguing orthogonally here: my question was really
about the persistency of a session handle, not really about
the question of a task (or any other SAGA object should have
one attached.

Cheers, Andre.

`
> 
> 
> Thilo
-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+