AL : Lock

A lock is placed on a node by calling node.lock(boolean isDeep). The node on which a lock is placed is called the holding node
of that lock.


Shallow and Deep Locks

A lock can be specified as either shallow or deep. A shallow lock applies only holding node and its properties. A deep lock applies to its holding node and descendants. Consequently, there is a distinction between a lock being held
node and a lock applying to a node. A lock always applies to its holding node. However, if it is a deep lock, it also applies to all nodes in the holding node's subgraph. When a lock applies to a node, that node is said to be locked.

Lock Owner

Initially, the session through which a lock is placed is the owner of that lock. This means the session has the power to alter the locked node and to remove the lock.

Repositories may support client-specified lock owner information.


Placing and Removing a Lock

When a lock is placed on a node, it can be specified to be either a session-scoped lock. A session-scoped lock automatically expires when the session through which the lock owner placed the lock expires. or can is released througt explicitly unlocked


Getting a Lock

node.getLock() returns the Lock object that applies to the node. if session is not same, lock cant called unlock()

void lock.unlock()
Removes the lock


Testing for Lock Holding

boolean node.isLocked()

returns true if the node holds a lock; otherwise returns false. To hold a lock means that the node has actually had a lock placed on it specifically, as opposed to having a lock apply to it due to a deep lock held by a node above.


Lock Object

The Lock object represents a lock on a particular node. It is acquired either on lock creation through node.getLock() 


[Example Code]
  Node parent = session.createNode(root, objectType, "parent");
  Node child = session.createNode(parent, objectType, "child");
  boolean isDeep = true;
  parent.lock(isDeep);
  assertTrue(child.isLocked());
  assertTrue(parent.isLocked());

  Lock lock = parent.getLock() ;
  lock.unlock();
  assertFalse(child.isLocked());
  assertFalse(parent.isLocked());



<Inteface Lock>
 public Node getNode() throws RepositoryException; // Getting the Lock Holding Node
 public boolean isDeep(); // Testing Lock Depth
 public void unlock() throws RepositoryException, InterruptedException;
 public boolean isOwner(UserBean user); // Testing Lock Owning Session


LockException

When a method fails due to the presence or absence of a lock on a particular node a LockException is thrown.
LockException extends RepositoryException,


종종 내가 특정 노드를 수정하고 있을때 (즉 edit Mode일때) 다른 누군가가 수정을 할 수 없게 하고 싶을 경우가 있다.
그러나 잘 알다시피 웹은 디스커넥트 환경이기 때문에 이러한 Lock의 구현이 조금 다르다.

첫번째로 했던 방법은 editMode로 갈때 userId와 node.UUID를 특정 테이블에 표시를 해두는 방식이다. 그리고 editMode로 들어가기 전에 이런 표시가 있는지 살펴보는 뻔한 방식을 생각해 볼 수 있다. 이 방법의 단점은 첫번째 사용자가 editMode에서 다른 사이트로 가버리거나 브라우저를 끄고 놀러가버렸을 때이다.

적절한 process를 거쳐 취소나 저장을 누르지 않은 상태에서 다른 곳으로 가버렸기 때문에 먼저 마크했던 정보가 여전히 남아있어서 다른 사용자는 여전히 접근할 수 었다는 단점이 있다. 관리자가 수동으로 풀어주는 것도 한두번이다.

두번째의 문제는 editMode로 갈때와 viewMode일때의 구분이 어렵다는 것이다. 모두 select이며 이걸 viewMode로 쓸지 editMode로 쓸지는 전적으로 프로그램에게 달려 있다.

또 다른 문제는 만약 setProperty시 Lock을 건다고 해도 commit까지의 시간이 아주 짧아(ns 레벨) 효과가 아주 미비하고 추가적으로 관리해야 할  Lock정보가 너무 많아지는 문제가 있다.



그래서 AL에서는 DB에서 사용하는 Lock 개념과 좀 달리 접근할 필요가 있었다.

첫번째 DB등의 persitence에 마킹하는 방법은 사용자가 다른 곳으로 가버렸을때나 AL의 restart등에도 남아있기 때문에 Lock 정보는 메모리에서 관리한다.

두번째 최소한의 정보를 관리하기 위해 Lock은 별도로 호출하기 전까지는 자동으로 걸리지 않는다.

세번째 Lock은 얼마의 시간이 지나면 자동으로 release 된다.



첫번째와 세번째 조건을 만족하기 위한 가장 좋은 장소는 Session이다. http Session이 아니라 AL은 웹과 상관없이 자체적으로 Session을 관리한다. session은 일정 시간이 지나도록 행동이 없으면 자동으로 invalidate 되기 때문에 위 조건을 만족할 수 있다.

두번째로는 node.lock() 을 호출하는 순간에만 lock이 걸린다. lock이 걸린다고 setProperty를 호출 할 수 없는 것은 아니다. 다만 node.isLocked에서 반환되는 값이 달라질 뿐이다.

명시적으로 해제하고 싶으면 해당 Owner가 node.getLock().unlock()를 호출해야 한다. 추가적으로 lock escalation으로 관리해야 할 락을 줄인다.