commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ozeigerm...@apache.org
Subject cvs commit: jakarta-commons-sandbox/transaction/xdocs/locks tutorial.xml index.xml
Date Sun, 31 Oct 2004 14:06:24 GMT
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


Mime
View raw message