With the Resource API milton exposes the semantics of locking as a java
API, and the requirement has been for users of milton to implement their
own lock persistence mechanism. The milton implementation integrates
checks of lock state into webdav operations, so you only need implement
persistence and retrieval, not checking.
However, with the annotations framework milton offers a higher level
abstraction, you dont need to implement persistence and retrieval of
locks, you only need to implement a unique ID on each resource so that
miltons internal LockManager has something to key on.
With the latest build of milton (22.214.171.124) there are 2 significant
changes that affect locking in the annotations framework.
- The SimpleLockManager, which is used by default to hold locks in the
annotations framework, now ignores the lockedByUser field sent in lock
requests, and instead uses the authenticated username. I've found that
this greatly improves compatibility with Mac Finder.
- The SimpleLockManager now uses a pluggable CacheManager to store the
locks. By default this is a local LRU concurrent map with a maximum of
1000 locks (configurable). However, if you're operating in a cluster you
really want to share lock information between servers. I've added a
CacheManager implementation that uses hazelcast for cluster wide sync of
locks - HazelcastCacheManager. If you want to use it you need to create
your own configuration file for hazelcast (or use the default) and you
need to create an instance and set it on the HttpManagerBuilder
HazelcastCacheManager hcm = new HazelcastCacheManager();
The SimpleLockManager will be wired up to it automatically as part of
the HttpManager stack building process.
There are no changes to locking in the Resource API, but if you're
working with the Resource API you are able to use SimpleLockManager and
Note that 126.96.36.199 is not yet the official release.