commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Zeigermann <>
Subject Re: Transaction API, GenericLock, FileResourceManager
Date Mon, 27 Jun 2005 06:30:36 GMT
Hi Aaron!

On 6/24/05, Aaron Hamid <> wrote:
> Hi all,
>   I suspect I just reimplemented FileResourceManager, because I was not aware of it until
recently (despite using the org.apache.commons.transaction.locking package).  Basically I
created a hierarchical Node interface, with operations like: children() and read(), which
implicitly obtain a readlock; write(), which upgrades to a write lock; and close() which releases
the locks.
> First, I'm wondering if there is a way to list a directory through the API, which itself
requires a read lock, or whether I must explicitly obtain the lock, and then perform the listing
externally (which is cumbersome).

The FileResourceManager is more low level than your approach. It does
not have the notion of hierarchichal data and thus no idea of

> Also, I'm curious as to the significance of the "owner" parameter to the lock API.  For
instance, I keep lock objects as a member field of Node implementations, using the unique
path as a resource id:

The "owner" is whatever object owns, i.e. holds, the lock. This can
e.g. be a thread, a process, a transaction, an application or
whatever. In "normal" Java locking this would be the thread.

> public class NodeImpl {
>   private ReadWriteLock lock;
>   private Node parent;
>   public NodeImpl(Node parent, Path path, Store store) {
>     lock = new ReadWriteLock(new StorePath(store, path), null);
>   }
>   public void open() {
>     // should I send 'this' as owner?
>     lock.acquireRead(this, Long.MAX_VALUE);
>   }
>   public void openForWriting() {
>     // should I send 'this' as owner?
>     lock.acquireWrite(this, Long.MAX_VALUE);
>   }
>   public void write() {
>     parent.openForWriting();
>     this.openForWriting();
>     // .. do some writing ..
>   }
>   public void close() {
>     lock.release();
>   }
> }
> Now...what should the value of the "owner" object be?  Should it naively be the 'this'
object?  Or should it be the Thread.currentThread(), or is it completely irrelevant and only
for informational purposes?  As you can see, to perform any writing, I must also lock the
parent node (for instance, if the write creates a new file...we can't allow reads/listings
to be happening).  However, the parent node, in this implementation, will obtain the lock
with an owner value of itself.  Now, I intend Node usage to only be single-threaded anyway
(the strategy being other threads would obtain a distinct node object, and not share node
objects accross threads)...but in any case, is this still legitimate, or should I be obtaining
the parent lock with some /other/ value of owner?  If I used distinct owners with that prevent
the child not from acquiring the lock, even though it is in its own thread?  The semantics
of "owner" don't seem to be very well documented.

I thought the notion of an "owner" was rahter obvious. Anyway, if you
have a single threaded application, why use locking?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message