You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by oz...@apache.org on 2004/10/31 15:06:24 UTC
cvs commit: jakarta-commons-sandbox/transaction/xdocs/locks tutorial.xml index.xml
ozeigermann 2004/10/31 06:06:24
Added: transaction/xdocs/locks tutorial.xml index.xml
Log:
Added locking documentation - work in progress
Revision Changes Path
1.1 jakarta-commons-sandbox/transaction/xdocs/locks/tutorial.xml
Index: tutorial.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Locking tutorial</title>
<author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
</properties>
<body>
<section name="Locking tutorial">
<p>
</p>
</section>
</body>
</document>
1.1 jakarta-commons-sandbox/transaction/xdocs/locks/index.xml
Index: index.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Locking</title>
<author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
</properties>
<body>
<section name="Locking">
<p>Locking refers to the procedure of restricting access to certain
resources like objects or files on your hard disk. Such a restriction
might be necessary to guarantee validity and consistency of data and
concurrent scenarios. E.g. consider two independent threads trying to
write to one and the same file. The result would be undefined unless
same sort of restriction on access applied. Java already offers the
powerful and flexible high-level monitor concept. Every object
can be used as a monitor and an associated (invisible) lock is used
to protected critical secions in your code. Java 1.5 even introduces
explicite locking as an alternative.</p>
<p>This may sound like there really is no need for additional locking
classes - at least when you can use Java 1.5. If you can not it might
be nice to have something like a well tested read/write lock. Such a
lock allows many threads to acquire access when reading, but only a
single one to write. Or a critical section that is protected by
synchronized is not suffient for your needs and you want to lock a
certain resource for a longer period of time. Of course you can get
all this done with Object's wait and notify methods, but this really
is error prone and unpleasant work.</p>
<p>All this can be done with the locking package of the Transaction
Component. It offers multi level locks that allow you
to dramatically simplify many locking scenarios. In this locking
package you are not restricted to the usual lock types like e.g. an
exclusive lock or a read/write lock, but you have simple, but
powerful mechanisms to customize which lock types are
compatible. Maybe even more important you are decoupled from threads
as the locking agents and are completely free to ascribe the lock to
a process, a request or any other Java object you would like. Both
the transactional maps and the transactional file system make heavy
use of them.
</p>
<p>To learn more about multi level locks and how you can use them continue
with the <a href="tutorial.html">tutorial</a>. It explains how
Jakarta Slide's WebDAV layer uses them to deadlock free avoid conflicts.</p>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org