[DRMAA-WG] DRMAA2 Draft 6, next steps, no conf call

Mariusz Mamoński mamonski at man.poznan.pl
Fri Jun 24 00:24:12 CDT 2011


2011/6/24 Andre Merzky <andre at merzky.net>:
> 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.

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


More information about the drmaa-wg mailing list