Re: [saga-rg] persistent session management?
[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/
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@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
On Fri, Jul 29, 2005 at 02:28:46PM +0200, Andre Merzky wrote:
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?
OK, let's have a nap with the new short spec... and let's get back to this next week. Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/
Yep, lets do that. Cheers, Andre. Quoting [Thilo Kielmann] (Jul 29 2005):
OK, let's have a nap with the new short spec... and let's get back to this next week.
Thilo
-- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+
participants (2)
-
Andre Merzky -
Thilo Kielmann