[Contrib: Evaluation System] AARON: Advice about dao.obtainLock()

[Jim Eng]

Thanks, Aaron.  I agree about not fitting into any of the existing interfaces. I went through each of them and didn't find a good home for these methods.  You are correct that they are just a copy of the dao methods, and the impls simply call the dao methods.  I thought about the possibility of throwing an exception in case of a null return value at the logic layer, but that didn't seem necessary. 

Again, thanks for taking a look at this. 

Jim  


On Dec 9, 2011, at 9:29 AM, Aaron Zeckoski wrote:

> That should work. Looks like this signature is basically just a copy
> of the DAO methods but this should avoid a dependency loop as long as
> it is not used from anything which does not have access to the DAO
> currently.
> This could probably go in one of the existing interfaces though it
> doesn't really fit in one of them all that well.
> -AZ
> 
> 
> On Thu, Dec 8, 2011 at 10:43 AM, Jim Eng <jimeng at umich.edu> wrote:
>> I'd like to propose a "LockManager" interface as shown below.  The impl
>> would be a class that just calls the corresponding dao methods.  Would this
>> make sense?
>> 
>> Jim
>> 
>> package org.sakaiproject.evaluation.logic;
>> 
>> /**
>>  *
>>  *
>>  */
>> public interface EvalLockManager {
>> 
>>     /**
>>      * Allows a lock to be obtained that is system wide,
>>      * this is primarily for ensuring something runs on a single server only
>> in a cluster<br/>
>>      * <b>NOTE:</b> This intentionally returns a null on failure rather than
>> an exception since exceptions will
>>      * cause a rollback which makes the current session effectively dead,
>> this also makes it impossible to
>>      * control the failure so instead we return null as a marker
>>      *
>>      * @param lockId the name of the lock which we are seeking
>>      * @param holderId a unique id for the holder of this lock (normally a
>> server id)
>>      * @param timePeriod the length of time (in milliseconds) that the lock
>> should be valid for,
>>      * set this very low for non-repeating processes (the length of time the
>> process should take to run)
>>      * and the length of the repeat period plus the time to run the process
>> for repeating jobs
>>      * @return true if a lock was obtained, false if not, null if failure
>>      */
>>     public Boolean obtainLock(String lockId, String executerId, long
>> timePeriod);
>> 
>>     /**
>>      * Releases a lock that was being held,
>>      * this is useful if you know a server is shutting down and you want to
>> release your locks early<br/>
>>      * <b>NOTE:</b> This intentionally returns a null on failure rather than
>> an exception since exceptions will
>>      * cause a rollback which makes the current session effectively dead,
>> this also makes it impossible to
>>      * control the failure so instead we return null as a marker
>>      *
>>      * @param lockId the name of the lock which we are seeking
>>      * @param holderId a unique id for the holder of this lock (normally a
>> server id)
>>      * @return true if a lock was released, false if not, null if failure
>>      */
>>     public Boolean releaseLock(String lockId, String executerId);
>> 
>> }
>> 
>> 
>> 
>> On Dec 8, 2011, at 10:27 AM, Jim Eng wrote:
>> 
>> Hi Aaron,
>> 
>> The eval dao has methods to obtain and release a lock, with the primary
>> intention being that a server obtains a lock on a process so it is done by
>> one and only one server in the cluster.  This seems perfect for what I want
>> to do in
>> org.sakaiproject.evaluation.logic.scheduling.ConsolidatedNotificationsJobImpl,
>> but it doesn't seem like it's available there.  The classes in that package
>> use the logic-layer rather than the dao.  Other than a few test classes, the
>> only places I see the dao.obtainLock() method called is within two methods
>> in the authoring service and the eval setup service.  I would like to call
>> dao.obtainLock() at the beginning of the execute() method in
>> ConsolidatedNotificationsJobImpl and then release the lock at the end of
>> that method.
>> 
>> Would it make sense to add methods similar to dao.obtainLock() and
>> dao.releaseLock() to one of the logic interfaces so they could be used in
>> places where the dao should not be accessed?
>> 
>> I'd appreciate any advice you can give.
>> 
>> Thanks.
>> 
>> Jim
>> 
>> 
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> 
>