2011/6/24 Andre Merzky <andre@merzky.net>:
2011/6/23 Mariusz Mamoński <mamonski@man.poznan.pl>:
2011/6/23 Andre Merzky <andre@merzky.net>:
Hi Mariusz,
line 1069: Should we state that is enough that session names must be unique for tuple (DRMS,user)
line 1097: Should we explicitly mention when one can call the destroySession ? If yes i would propose "only for not opened session".
These two items together imply that it is an error if I open a session in one application instance, and destroy it in another instance which runs at the same time. Which instance will show the error? Both? How is synchronization done?
I think opening the same session **concurrently** in two application falls into "invalid usage".
Then that needs to be documented in the spec.
FWIW, this will be very hard on the end user. For example, tool developers which build tools upon DRMAA have no control over how the tools are used, and how instances are synchronized. This will be particularly difficult as sessions are supposed to be persistent, and thus are *supposed* to be used (i.e. opened) in different application instances.
this is still possible but sequentially not concurrently and i think it serves most of the use cases. I guess it typically would be the same application but different run. I think one of the idea of introducing the restartable session concept in DRMAA 2.0 was that in DRMAA 1.0 you had to (in theory) keep the application running as long as you had some job in the system.
I don't see a better solution - just saying. I guess at the end this will only really work if the DRM system can support the session state's persistence...
Cheers, Andre.
The fundamental problem seems to be that the spec introduces stateful sessions which do not (necessarily) have any state management in the backend. If you library itself is maintaining the state, you will introduce race conditions.
Cheers, Andre.
-- Nothing is ever easy...
-- Mariusz
-- Nothing is ever easy...
-- Mariusz