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

[Aaron Zeckoski]

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