[DRMAA-WG] misssing exceptions and thread safety

[Daniel Templeton]

The atomicity has to be managed at the DRM layer.  The suspend call has 
to operate like a test and set operation.  If the suspend operation 
doesn't return notification whether the job was already suspended, then 
the DRMAA implementation can't report it via an exception.  There is, 
however, no need to make the exception explicitly optional.  Exceptions 
are by definition optional.

Daniel

On 03/01/10 02:38, Daniel Gruber wrote:
> On 03/01/10 11:17, Andre Merzky wrote:
>> Quoting [Daniel Gruber] (Mar 01 2010):
>>    
>>>     Hi,
>>>     while scanning the wiki I found following:
>>>     The Job object methods should throw following exceptions:
>>>     - "JobAlreadySuspendedException" from suspend method when
>>>       job is already suspended. The DRMAA implementation have
>>>       to make sure that suspend job is just called once. It is not enough
>>>       for the DRMAA implementation to rely on own state, it should
>>>       check the state automatically in order to avoid problems when
>>>       the state is set outside of DRMAA. Should DRMAA deal with
>>>       such cases?
>>>      
>>
>> *Can* DRMAA deal with such cases?  These are two operations which
>> are usually not atomic (1: check for state, 2: suspend) - so how can
>> a DRMAA client side library ensure that the remote state does not
>> change between these two calls, e.g. due to a 3rd part API call?
>>
>> I guess it's ok to throw when the backend replies with that error
>> (job already suspended) - but requiring the DRMAA implementation to
>> ensure atomicity is most likely futile.
>>
>> my $0.02, Andre.
>>
>>    
> You're right - atomicity seems not to be possible.
>
> Another important thing to know would be if all DRMs are throwing such 
> an exception
> or are there any which are silently ignore second request and telling 
> again that it
> is suspended (suspend is idempotent). Do we have than a problem with 
> the spec saying
> that there is an Exception but on some implementations there will be 
> never throw one?
> We should make the exception optional if so.
>
> Cheers
>
> Daniel
>
>
>>    
>>>     - "JobNotSuspendedException" from the resume method (like above).
>>>     - "JobTerminatedException" when calling a method on a job
>>>        when the job is already terminated.
>>>        This is for "suspend" "resume" "hold" "release" "terminate"
>>>     "waitStarted"
>>>     Obvious synchronization problems:
>>>     - accessing an already "deleted" JobTemplate: here that same as for a
>>>     destroyed Session should apply (InvalidJobTemplateException)
>>>     - accessing a job template while "deleting" (running a job or accessing
>>>     otherwise): here that same as for a destroyed Session should apply
>>>     (InvalidJobTemplateException)
>>>     - write access for the job templates must be synchronized by the DRMAA
>>>     implementation
>>>     - Is there a need to make the invalid state of a JobTemplate (that is
>>>     when a JobSession
>>>       has been closed) as an accessible field or should every problem
>>>     covered by the
>>>      "InvalidJobTemplateException"?
>>>     Regards
>>>     Daniel
>>>      
>
>
> --
>    drmaa-wg mailing list
>    drmaa-wg at ogf.org
>    http://www.ogf.org/mailman/listinfo/drmaa-wg
>