[Bacula-commits] bacula/doc/latex dirdconf.tex,1.30,1.31

[Kern S. <ke...@us...>]

Update of /cvsroot/bacula/bacula/doc/latex
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11065/doc/latex

Modified Files:
	dirdconf.tex 
Log Message:

- Comment out Multiple Connections in the document.
- Move the P() and V() to subroutines so that they can be accessed
  from class methods. The reference to strerror() caused problems.
- Implement new DEVICE class methods block() and unblock() that
  do what was previously done in 3 lines of code.
- Implement wait_for_device(), which will wait for any device
  to be released then return. This requires a new global mutex
  and condition variable, and is implemented in src/stored/wait.c
- Change the code in reserve_device_for_read(), which previously
  failed the job to use the new device wait code.

Index: dirdconf.tex
===================================================================
RCS file: /cvsroot/bacula/bacula/doc/latex/dirdconf.tex,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- dirdconf.tex	18 Mar 2005 17:22:27 -0000	1.30
+++ dirdconf.tex	26 Mar 2005 07:58:42 -0000	1.31
@@ -2983,25 +2983,26 @@
 access the  database if it is on another machine. This directive is used  only
 by MySQL and is ignored by SQLite if provided. This  directive is optional.  
 
-\item {\bf Multiple Connections = \lt{}yes|no\gt{}}
-\index[console]{Multiple Connections  }
-By default, this  directive is set to no. In that case, each job that uses the
-same Catalog will use a single connection to the catalog. It will  be shared,
-and Bacula will allow only one Job at a time to  communicate. If you set this
-directive to yes, Bacula will  permit multiple connections to the database,
-and the database  must be multi-thread capable. For SQLite and PostgreSQL,
-this is  no problem. For MySQL, you must be *very* careful to have the 
-multi-thread version of the client library loaded on your system.  When this
-directive is set yes, each Job will have a separate  connection to the
-database, and the database will control the  interaction between the different
-Jobs. This can significantly  speed up the database operations if you are
-running multiple  simultaneous jobs. In addition, for SQLite and PostgreSQL,
-Bacula  will automatically enable transactions. This can significantly  speed
-up insertion of attributes in the database either for  a single Job or
-multiple simultaneous Jobs.  
+%% \item {\bf Multiple Connections = \lt{}yes|no\gt{}}
+%% \index[console]{Multiple Connections  }
+%% By default, this  directive is set to no. In that case, each job that uses the
+%% same Catalog will use a single connection to the catalog. It will  be shared,
+%% and Bacula will allow only one Job at a time to  communicate. If you set this
+%% directive to yes, Bacula will  permit multiple connections to the database,
+%% and the database  must be multi-thread capable. For SQLite and PostgreSQL,
+%% this is  no problem. For MySQL, you must be *very* careful to have the 
+%% multi-thread version of the client library loaded on your system.  When this
+%% directive is set yes, each Job will have a separate  connection to the
+%% database, and the database will control the  interaction between the different
+%% Jobs. This can significantly  speed up the database operations if you are
+%% running multiple  simultaneous jobs. In addition, for SQLite and PostgreSQL,
+%% Bacula  will automatically enable transactions. This can significantly  speed
+%% up insertion of attributes in the database either for  a single Job or
+%% multiple simultaneous Jobs.  
+
+%% This directive has not been tested. Please test carefully  before running it
+%% in production and report back your results.  
 
-This directive has not been tested. Please test carefully  before running it
-in production and report back your results.  
 \end{description}
 
 The following is an example of a valid Catalog resource definition: