[DRMAA-WG] DRMAA2 Draft 6, next steps, no conf call
andre at merzky.net
Thu Jun 23 17:16:23 CDT 2011
2011/6/23 Mariusz Mamoński <mamonski at man.poznan.pl>:
> 2011/6/23 Andre Merzky <andre at 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.
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
>> 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...
Nothing is ever easy...
More information about the drmaa-wg