NSS Shared DB: Difference between revisions

Jump to navigation Jump to search
Line 1: Line 1:
== Shared Database Proposal ==
== Shared Database Proposal ==


NSS has been using an old version of the Berkeley DataBase as its database engine since Netscape Navigator 2.0 in 1994. That version of the database engine is commonly described in NSS documents as "DBM".  That engine has a  
NSS has been using an old version of the Berkeley DataBase as its database engine since Netscape Navigator 2.0 in 1994. This database engine is commonly described in NSS documents as "DBM" and has a  
number of limitations.  One of the most severe limitations concerns the  
number of limitations.  One of the most severe limitations concerns the  
number of processes that may share a database file.  While any process has  
number of processes that may share a database file.  While any process has  
Line 22: Line 22:
own shared database implementation, and configured NSS to use it.   
own shared database implementation, and configured NSS to use it.   


Today, there exists a process level, ACID, open source, and widely available database engine with which multiple processes may simultaneous have read and write access to a shared database.  It is named SQLite.  The NSS team proposes to leverage this database to give all NSS-based applications Shared Database access.
Today, there exists a process level, ACID, open source, and widely available database engine with which multiple processes may simultaneous have read and write access to a shared database.  It is named SQLite.  The NSS team proposes to use this database to give all NSS-based applications Shared Database access.


Besides the inability to share databases, other issues with NSS DBM database scheme include:
Besides the inability to share databases, other issues with NSS DBM database scheme include:
Line 39: Line 39:
Also in that directory:<br />
Also in that directory:<br />
* If it has very large security objects (such as large CRLs), NSS will store them in files in a subdirectory named cert8.dir.
* If it has very large security objects (such as large CRLs), NSS will store them in files in a subdirectory named cert8.dir.
* If the cert8.db and/or key3.db files are missing, NSS will read data from older versions of those databases (e.g., cert7.db, cert5.db, if they exist)  
* If the cert8.db and/or key3.db files are missing, NSS will read data from older versions of those databases (e.g., cert7.db, cert5.db, if they exist) and may build new cert8.db and/or key3.db files with that data (upgrade).
and may build new cert8.db and/or key3.db files.


These files are all accessed exclusively by the softoken shared library, making it the only NSS library that must be linked with libdbm.
These files are all accessed exclusively by the softoken shared library, making it the only NSS library that must be linked with libdbm.
439

edits

Navigation menu