@(#) LSARC Questions Version 2.0t @(#)LSARC 1.29 05/10/02 __________________________________________________________________ __________________________________________________________________ 0. Remind us: 0.1 The case number for this project? ARC 2007/299 0.2 This questionnaire is for an [x] Inception Review or [ ] Commitment Review 0.3 Name(s) of person(s) answering the questions? Karen Langford (karen.langford@sun.com) Rob Stephens (rob.stephens@sun.com) 1. What specifically is the proposal that we are reviewing? 1.1 The case owner will need to put a 1 to 4 paragraph description at the top of the Opinion document. Suggest text for it. Please be specific about deliverable components and their interfaces. Berkeley DB (BDB) is a low-level database API. This API allows an application to store data into a record-based data store. This API does not implement SQL and is not inherently relational in nature. It is basically an interface into a persistent record store. BDB 4.2.52, approved by ARC (2003/585), is currently used by a number of Sun products and is available in Nevada/S10 and the Java Enterprise System as a shared component. This ARC case is to establish BDB 4.5.20, the latest version of the Berkeley Database, as an accepted database technology for product use within Sun, including Solaris, and the Sun Java Enterprise System. We propose to deliver BDB 4.5.20 and BDB 4.2.52 (for backwards compatability's sake) in the same package. BDB is delivered in source form. The Database Technology Group is responsible for building the binaries for all platforms required by Java Enterprise System and Java Desktop System. Builds for other platforms will be handled on an as-needed basis. The Database Technology Group is also responsible for support and maintenance of BDB. BDB can also be shipped as open source with any open source projects. For more information see http://onestop/technology/berkeley.shtml?menu 1.2 Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change and why? (See the document in /shared/sac/doc/release.taxonomy.) Many products within Sun are using BDB 4.2 which has been ARCed as a shared component. We do expect there to be some period of time where this older version of BDB may need to exist simultaneously with the newer version, until such time as all products have been able to successfully upgrade to the new version. The upgrade from BDB 4.2 to 4.5 is minor. 2. What is the motivation for it? What are the expected benefits for Sun? By what criteria will you judge its success? Allows our products to use the latest of Berkeley BDB Technology. We know we are "done" when we have integrated BDB 4.5 into Nevada as a shared component. 3. The plan: 3.1 Who (what groups in what business units) are working on it? The Database Technology Group under Heidi Bergh-Hoff. 3.2 What is the current status? This is a follow on release to BDB 4.2, all processes are in place. 3.3 Has a design review been done? N/A 3.4 What Product Approval Committee (PAC) do you expect to approve this project? Database Technology PAC 4. Related Projects: 4.1 What not-yet-delivered Sun projects (libraries, hardware, etc.) does this project depend upon (i.e., need to be successful)? None 4.2 What non-Sun projects does this project depend upon? None 4.3 What other projects depend on this one? Solaris and Nevada Access Manager Directory Server Messaging Server Message Queue Mail Server Calendar Server Evolution PHP Flexline 600 & Virtual Storage Manager ( StorageTek ) Identity Server Instant Messaging Mars Keystone Niagra / Rock SP N1 Sun Cluster N1 Grid Portal Server NSS Open Office OPL StarOffice WPSync Sendmail Solaris SNMP Agent CDE Tooltalk Solaris Encryption Framework SJS Web Server 4.4 What other active projects at Sun are related to your project, and how are they related? See above 4.5 What future projects should be started or avoided to help your project succeed, and why? None 5. What technical approach has been selected by the project? N/A 6. How is the project delivered into the system? Is it bundled or unbundled? BDB 4.2 is bundled into Solaris as a shared component. It is also delivered into Java Enterprise System as a shared component. BDB 4.5 will be likewise bundled and delivered as a shared component. What are your delivery vehicles (WOS, CTEAM...) For Solaris and Nevada: CTEAM: Shared Component Cluster id: SUNWCbdb Metaclusters: SUNWCXall, SUNWCall, SUNWCprog, SUNWCuser, SUNWreq Cluster name: BerkeleyDB-Base 4.5.20 Packages: SUNWbdb, SUNWbdbj for the backwards compatibilities sake We will deliver the 4.2.52 binaries within the same package. Identify package abbreviations, directory names, library names, databases, etc. SUNWbdb SUNWbdbj See 10.11 for full list of directory/library names. 7. Hardware Platform Dependencies: 7.1 What are the project's hardware platform dependencies, including Sun or third-party add-on hardware that is explicitly supported. None 7.2 Are Solaris components expected to work on SPARC and Intel? If not, why? What will be affected in porting? Any problems if porting to another architecture were desirable? N/A 7.3 Are there issues with "binary" interfaces, which would be incompatible on various instruction set architectures? No 7.4W For Microsoft Windows components, what is the minimal hardware configuration supported (e.g., Intel 386 with 8mb of memory)? There is no documented minimal hardware configuration. For a standard build, all Win32 platforms are supported. Due to the different applications that may be deployed with Berkeley DB, an exact memory requirement is difficult to ascertain. However, 64mb of memory is recommend when running the standard test suite. 8. Compatibility and Interoperability (Consider a compatibility matrix, if the information is nontrivial.) 8.1 OS compatibility: 8.1.1 For Solaris components, what Solaris release(s) does it run on or work with? SunOS5.9 SunOS5.10 SunOS5.11 8.1.2 Does it run on Linux? What distribution(s)n and version(s)? Yes. RHEL 3.0, 4.0, 5.0 Suse SLES 10 (32/64 bit) It can be built for other versions as required by product groups. 8.1.3 Might the project need any extra adaptation to work successfully with future (i.e., later) releases? patches? Some emergency fixes may need to be applied by a particular product group; we will provide branches off of the main source tree for such fixes. We expect these fixes to be incorporated into some future release and do not expect these "emergency branches" to be long lived. As yet we have not had to employ this procedure. 8.1.3 For Microsoft Windows components, does it run on Windows 3.x? Windows 95/98/ME? NT/W2K/XP? It runs on any Win32 platform 8.2W Does it depend on features and software that exist only in certain versions of Windows, such as networking features not in XP Home? No 8.2S Do Solaris components depend on kernel features not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional loadable kernel modules)? What packages or clusters must be installed first (if the "core" set of packages is insufficient)? Do the packages express those dependencies explicitly? No 8.3 Do Solaris components use any system interfaces, commands, or features not in X/Open CAE SUSv2 and XNS5? No 8.4 Do Linux components use any interfaces, commands, or features not in the Linux System Base 1.3? No 8.4 With what releases of what other projects or products does this project interoperate? Using what interfaces? (Provide reference to ARC case approving these interfaces or a specification and proposed stability classification for the interfaces.) None 8.5 What internationalization (I18n) issues are involved? What languages *can* be supported by localization without modifying the base product, whether or not a localization is currently planned? What I18N interfaces will the project adhere to? If strings are used, how are they accessed -- Solaris-mostly gettext(), X/Open catgets(), GNU gettext? What items and interfaces are (or are not) being internationalized? The product is not internationalized. 8.6 Are there any existing or proposed standards it conforms to or deviates from? Examples: SPARC/Intel ABI, OMG/CORBA, POSIX, SVID, XPG (X/Open Portability Guide), RFCs, national or international standards. Include version numbers. No 8.7 Can this version co-exist or interoperate with earlier and later versions? Yes with alternative implementations (perhaps by other vendors)? Possibly Is switching between installed versions or implementations possible? What is involved? In order to switch between installed versions, the customer needs to rebuild their application, ie: build against the new libraries. Note the database format is the same, but log files change between versions. 8.8 Does the project move, disable, delete, circumvent or change any files, components, or services outside the project? No 8.9 Does it use any interfaces (for example, a driver using kernel structures) that are private to another consolidation? read or write /dev/kmem? trap directly into the kernel, instead of via libc functions? No 8.10 What components (e.g., libraries or packages) are shared with other projects or products? All the BDB libraries are shared with other project/products across SMI (see dependent products in section 4.3) 8.11 Can customization (e.g., OEM relabeling) be accomplished via resource files that are separable from the source code? No 8.12 Device Drivers: NA 9. Technical Content 9.1 Architecture Diagram: Include in case materials an Architecture Diagram, showing the major components, major interfaces, and all customer-visible interfaces and inter-project interfaces. Give each a number or brief name for use in the Interface Table below. See [1] Architecture.pdf included with case materials. 9.2 Interface Table: Include Imported and Exported Interface Tables showing all customer-visible interfaces and inter-project interfaces and significant internal interfaces (inter-subsystem and inter-invocation). Interfaces are not just function calls. Include user interfaces (graphical, browser based, character based), configuration files, XML schemas, network protocols, port numbers, etc. EXPORTED INTERFACES: Proposed Specified Former Stability Interface Stability in what Classification Name Classification document? or Other Comments ------------------ ------------- -------------- -------------------- IF1 - C API External [3] IF2 - C++ API External [4] IF3 - Java API External [5] IF4 - TCL API External [6] IF5 - Repl API EXternal [7] IF6 - DB_HOME env External [8] Used to configure the variable location of db files. IF7 - DB_CONFIG External [9] Used to configure a config file database IF8 - database file Project Private IF9 - transaction log Project Private IF10 - temporary backing Project Private files IF11 - db_archive Unstable [10] IF12 - db_checkpoint Unstable [11] IF13 - db_deadlock Unstable [12] IF14 - db_dump Unstable [13, 22] IF15 - db_hotbackup Unstable [14] IF16 - db_load Unstable [15, 22] IF17 - db_printlog Unstable [16] IF18 - db_recover Unstable [17] IF19 - db_stat Unstable [18] IF20 - db_upgrade Unstable [19, 23] IF21 - db_verify Unstable [20] 9.3 Identify names and contents of packages, directories, libraries, databases, etc. Identify package abbreviations (SUNWxxx) and contents figuratively ("configuration command line utilities"). SUNWbdb - Berkeley DB for C/C++ applications SUNWbdbj - Berkeley DB for Java applications 9.4 Package manifest: Please see package manifest in document: sol_pkgmap.txt 10. The operational environment: 10.1 Command line or calling syntax: What options/operands are supported? N/A 10.1S Do they conform to PSARC/1999/645 command syntax guidelines, an extension of the Single Unix Specifications rules? Are any of the "CLIP" extensions N/A 10.1.1 Is there support for standard forms, e.g. X11(7) manpage's "-display", etc.? If not, why not? N/A 10.1.2 Are these options propagated to sub-environments? N/A 10.2 Can it be included in a shell pipeline? How does it use standard input, output and error? N/A 10.3 Environment Variables: 10.3.1 What environment variables are used? Describe values and semantics. DB_HOME is used to specify the location of database files. It must be a valid filesystem directory path. 10.3.2 What is the default behavior if the environment variable is not set? The current working directory is used. 10.3.3 What environment variables are set? None 10.4 For Solaris programs, what are their exit status values? What nonzero status values have what meanings? N/A 10.5W What inter-component Windows messages are sent or intercepted? None 10.5S Signals issued? Signals caught? (See "man(5) signal".) What are their semantics? The admin utilities catch SIGINT, SIGHUP, SIGPIPE and SIGTERM. When these signals are caught, the utilities first perform any necessary operations to ensure the database is in a consistent state, and then they exit. The BDB library catches no signals. 10.6 Device drivers directly used (e.g. /dev/audio)? None 10.7W SYSTEM.INI, WIN.INI or other resource/configuration files or databases? Describe any files used between invocations. Database file, transaction log are used between invocations. The location and duration of these files is controlled by the calling application. 10.7S .rc/defaults files, Java properties, GNOME GConf keys or other resource/configuration files or databases? N/A 10.8 Does it use any "hidden" files (filename begins with "."), system files, or temporary files? BDB creates temporary "backing" files. The purpose of these files is not clear as it is used internally. 10.9 Does it use any locking files? Does it use Solaris locking facilities? No 10.10 Can it execute remotely? In a distributed fashion? Is the user aware that the tool is executing remotely? BDB provides an RPC service however we do not deliver. 10.11W For each Windows component (EXE, DLL or VxD) identify the name of the component and module identifier (EXE/DLL) or VxD ID (VxD)? If a module provides a plug-compatible replacement for a standard system component, identify the component and its version. Indicate whether VxD IDs are officially registered. Here is a listing of the DLL and EXE files. db_archive.exe db_checkpoint.exe db_deadlock.exe db_dump.exe db_hotbackup.exe db_load.exe db_printlog.exe db_recover.exe db_stat.exe db_upgrade.exe db_verify.exe libdb45.dll libdb45.exp libdb_java45.dll libdb_java45.exp 10.11S Solaris Libraries If you have code, include output from both "dump -Lv" and "ldd"; but note that the ARC wants to know what the project will deliver, regardless of what developers currently have. We include output for the C and Java libraries. The other utilities have similar dependencies. == ldd for libdb.so.3 == libpthread.so.1 => /usr/lib/libpthread.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 librt.so.1 => /usr/lib/librt.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libthread.so.1 => /usr/lib/libthread.so.1 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1 /usr/platform/SUNW,Sun-Fire-880/lib/libmd5_psr.so.1 == dump Lv for libdb.so.3 == **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libpthread.so.1 [2] NEEDED libnsl.so.1 [3] NEEDED libsocket.so.1 [4] NEEDED librt.so.1 [5] NEEDED libc.so.1 [6] SONAME libdb.so.3 [7] RUNPATH /usr/lib [8] RPATH /usr/lib [9] HASH 0x94 [10] STRTAB 0x81c4 [11] STRSZ 0x5732 [12] SYMTAB 0x2bb4 [13] SYMENT 0x10 [14] CHECKSUM 0x2a8e [15] VERNEED 0xd8f8 [16] VERNEEDNUM 0x5 [17] PLTSZ 0x33b4 [18] PLTREL 0x7 [19] JMPREL 0x167b8 [20] RELA 0xd998 [21] RELASZ 0xc1d4 [22] RELAENT 0xc [23] FEATURE_1 PARINIT [24] FLAGS 0 [25] FLAGS_1 0 [26] PLTGOT 0x126e7c == ldd for libdb_java.so.3 == libpthread.so.1 => /usr/lib/libpthread.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 librt.so.1 => /usr/lib/librt.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libthread.so.1 => /usr/lib/libthread.so.1 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1 /usr/platform/SUNW,Sun-Fire-880/lib/libmd5_psr.so.1 == dump Lv for libdb_java.so.3 == **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libpthread.so.1 [2] NEEDED libnsl.so.1 [3] NEEDED libsocket.so.1 [4] NEEDED librt.so.1 [5] NEEDED libc.so.1 [6] SONAME libdb_java.so.3 [7] RUNPATH /usr/lib [8] RPATH /usr/lib [9] HASH 0x94 [10] STRTAB 0x9864 [11] STRSZ 0x9194 [12] SYMTAB 0x3334 [13] SYMENT 0x10 [14] CHECKSUM 0x54d6 [15] VERNEED 0x129f8 [16] VERNEEDNUM 0x5 [17] PLTSZ 0x33cc [18] PLTREL 0x7 [19] JMPREL 0x20a78 [20] RELA 0x12a98 [21] RELASZ 0x113ac [22] RELAENT 0xc [23] FEATURE_1 PARINIT [24] FLAGS 0 [25] FLAGS_1 0 [26] PLTGOT 0x147bc0 10.11.1 What dynamic (aka "shared") libraries does it use directly or indirectly, including via dlopen/dlsym(3x)? libpthread.so.1 libnsl.so.1 libsocket.so.1 librt.so.1 libc.so.1 libdl.so.1 libmp.so.2 libaio.so.1 libmd5.so.1 libthread.so.1 10.11.2 With what -R options will executables be built? None 10.11.3 Does it use any static libraries? No 10.11.4 What libraries does your project export? == Unix == libdb.so.3 libdb_java.so.3 == Windows == libdb45.dll libdb_java45.dll 10.12 Does your project use or ship database or persistent storage software? If not, skip the rest of this section. N/A 11. System Administration Interfaces: 11.1 How will the project's deliverables be installed? Platform deliverable ============== ================ Solaris Svr4 Pkgs Linux Rpm's HP depots Windows zip other tar 11.2 How will the project's deliverables be uninstalled? They will be uninstalled using pkgrm. 11.3 How will the project's deliverables be configured and reconfigured? All configuration will be done through the API. BDB does support a DB_CONFIG configuration file, but we are recommending this not be exposed to end users. 11.4 Does it need installation within any global system tables? No Does your package edit existing files in a common directory (/etc/vfstab for example)? If so, how do you remove your edits when your package is removed? If your package is reinstalled over itself, does it recognize that the edits are already there or does it make all new entries? No What Microsoft Windows registry entries are created or modified? None 11.5 Does your package use components of other unbundled packages? If so, how do you find those packages? No 11.6 Can your product be installed to an alternate filesystem (using "pkgadd -R") for use with diskless/auto clients or live upgrade? Yes 11.7 Can your product be installed anywhere on the target system and still function (is it relocatable)? (BASEDIR) Yes 11.7.1 Has your project changed or introduced any package procedural scripts (postinstall, preremove, etc)? If YES, are these scripts well-behaved with respect to alternate roots? That is, when these packages are added or removed using -R, do they cause any changes to be made to /? The correct answers are either "No" or "Yes, Yes, and No". No 11.8 Even relocatable packages may have one or two elements that *must* go in a certain place (/etc files for example). Are these "absolute" elements in the pkgmap or are they being installed with a postinstall script? If installed with a postinstall, how does the administrator check their integrity (how does pkgchk know about them)? No 11.9 How does a new version of your package upgrade a prior version? The new packages deliver both BDB 4.2 and BDB 4.5 and will not remove an old install of BDB. 11.10 Does your package replace a filesystem object delivered by a prior package? If so, how do you inform the other package that it doesn't own this file anymore? How do you return the original package to its original state if your package is pkgrm'd? No 11.11 Have you grouped generic functionalities that may be used by other projects into their own packages (KLG widgets, a third-party set of device drivers)? If not how do other projects know this generic functionality is installed? Are you using existing classes and libraries as far as possible? Yes. We have only two packages, both are shared by other projects. 11.12 How is it started? For a daemon: does it use inetd? If not, why not? It is loaded by the linker of the calling application. 11.13 Does it use a naming service such as NIS, DNS, LDAP? Directly, or through the name service switch? No 11.14 What are its on-going maintenance requirements (e.g. keeping global tables up to date, trimming files)? This depends upon the project using BDB. There are no inherent maintenance requirements, but a given project may want to implement backup, archiving, and other maintenance functions depending on their needs. There is no error/message log file. 11.15 Can administration be done from a remote machine? How? No, administration can only be done through the API or the utilities. Remote admin will need to be provided by the project using BDB. 11.16 Can all GUI administration also be performed without the GUI? How? N/A 11.17 What command or scripting language is used? N/A 11.18 Does the project include runtime license checking? How is it accomplished? No 11.19 Are there any restrictions or other architectural effects from contractual obligations, copyright restrictions, or technology royalty structure? See the Sun/Oracle license agreement. 12. The Window System/Desktop Operational Environment: 12.0 Does the project include a GUI (Graphical User Interface)? If not, say "NONE" and remove all this section's subsections. NONE 13. Brainstorming Interfaces (exported and imported): Include in your Interface Table any of the following that apply. You may comment on them here, if you wish. 13.1 Exported Library APIs and ABIs exposed to customers NONE 13.2 Protocols (public or private, including RPCs) NONE 13.3 Drag and Drop: what objects and what are the semantics? N/A 13.4 GNOME ORB (bonobo) remote calls, Web service calls (SOAP, etc.), ToolTalk messages? N/A 13.5 Files used as an interface, e.g. Resources, config files, etc.) See interface table 13.6 Significant file formats, names, syntax, and semantics? Is there an /etc/magic entry for any new file format? What will file(1) say? The database file format is important because if it changes, then an upgrade will require upgrading the database file as well as the libraries. The upgrade process is well documented by Berkeley DB, see [22] and [23]. The output of file(1) on a database file is “data” 13.7 Interfaces to applications it interoperates or communicates with? (Perhaps pipes, shared memory.) N/A 13.8 Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? No 13.9 Other External Interfaces? None 13.10 Brainstorming Significant Internal Interfaces 13.11 Protocols (public or private) None 13.12 Private ORB, RPC, SOAP, RMI, etc. transactions None 13.13 Files See interface tables 13.14 Do any internal interfaces save state across invocations? Yes, database file, database log 13.15 Other Internal Interfaces? See interface tables. 14. Questions for Every Interface: These questions should be asked for every one of the project's interfaces; the answers are therefore often listed in Section 9.2 (Don't repeat.) Only the interesting answers are normally discussed. 14.1 Propose the stability/commitment classification of the interface -- "Standard", "Stable" (formerly Public), "Evolving", "Unstable" (intentionally Uncommitted), Contract Private, etc. -- per the SAC Interface Taxonomy document in /shared/sac/doc/interface.taxonomy 14.2 Who controls the interface (i.e., could make changes to it)? Point out any interfaces not solely controlled by Sun. None of the interfaces are controlled by Sun 14.3 Interface Specification: 14.3.1 Where is the interface specified (documented)? See interface table 14.3.2 Is the specification complete enough for a re-implementation? N/A 14.3.3 Will the project deliver to customers documentation for the interface? None of the interfaces are public 14.3.4 Are the interfaces documented clearly enough for a non-Sun client to use them successfully? N/A 14.4 Interface Versioning and Projected Evolution 14.4.1 Present Change: if any interface is an update to or replacement for a previous one, what was the stability classification of the previous version? Is this backwards-compatible? Describe any migration story to mitigate the conversion. N/A 14.4.2 Future Evolution: Even if an interface is new, it should be prepared for evolution. How will a transition to a new version to be accomplished? What are the expected consequences to ISVs and users and administrators? What provisions are made now to minimize or manage the pain (to clients) of future evolution? We support interface versioning through shared-object library versioning. 14.4.3 For Microsoft Windows components that install on top of an existing product (such as PC-X on top of PC-NFSpro): are there common files that should only be upgraded if the files being installed have a new version? N/A 15. Performance and Scalability: This product is controlled by a third party, so we can't really control this. 15.2 Are there any limits to scalability, such as a fixed-size array forcing a maximum number of clients, users, simultaneous connections, etc.? Are any data structures (e.g., kernel structures) so huge that large numbers of them are impractical? No 15.3 Resource Consumption: 15.3.1 Attempt to describe resource consumption scaling, even crudely. For example, if each client consumes 1MB of memory, you could say: Memory_required = 1MB * N clients Berkeley DB doesn't create or destroy threads, and isn't aware of thread-local storage. So, DB doesn't tie down any specific memory on a per-thread basis. 15.3.2 Which resources are likely to be bottlenecks? For a database system, the disk is likely to be the main bottleneck. 15.4 Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? No 15.5 Multi-threading: What is your project's MT model? What must an MT client do to use your interface(s) safely? How does your project use threads internally? How does it expect its client to use threads? If it uses call-backs, can the called entity create a thread and recursively call back? The BDB Concurrent, Transactional and HA products are written to handle multiple concurrent clients in a highly scalable manner. The basic BDB Data Store product assumes a single-threaded model. 15.6 What is the impact on system performance (positive or negative)? BDB in itself has very little overhead, but an application which has a heavy load may cause heavy disk I/O, but this should not impact other applications running on the host. 15.6.1 What is the average memory usage or working set of this component? The working set depends solely on application usage and can vary widely. 15.6.2W How much of this is locked down? None 15.6.3W What system resources are consumed by each component under Windows 3.x? Under Windows 95? N/A 15.6.2S How much of this is shared/sharable by other apps? None 15.7 Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? No 15.8 Will it require large files/databases (for example, new fonts)? BDB is a database product... 15.9 Do files/databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? Generally, yes, but it depends upon the application. This is completely under the control of the application using it. 15.10 What are the project's effects on boot time requirements? None 16. Security: 16.1 What security issues do you address in your project? Please refer to the security section in the Berkeley DB Reference Guide, see [24] and [25]. In short, Berkeley DB database environments are directories, and they contain files, so both file and directory permissions are potential issues. DB also optionally uses environment variables, and creates temporary backing files, both of which are dangerous in some circumstances. There is also the issue of encryption. Berkeley DB optionally supports encryption using the Rijndael/AES (also known as the Advanced Encryption Standard and Federal Information Processing Standard (FIPS) 197) algorithm for encryption or decryption. The algorithm is configured to use a 128-bit key. Berkeley DB uses a 16-byte initialization vector generated using the Mersenne Twister. All encrypted information is additionally checksummed using the SHA1 Secure Hash Algorithm, using a 160-bit message digest. The encryption support provided with Berkeley DB is intended to protect applications from an attacker obtaining physical access to the media on which a Berkeley DB database is stored, or an attacker compromising a system on which Berkeley DB is running but who is unable to read system or process memory on that system. The encryption support provided with Berkeley DB will not protect applications from attackers able to read system memory on the system where Berkeley DB is running. For more information, see the "Encryption" section of the Berkeley DB Reference Guide. 16.2 What security concerns might customers or reviewers have? Reviewers often worry about things like buffer overflows. BDB has been careful to avoid buffer overflows (especially when dealing with strings that are provided to the Berkeley DB library by the application, and possibly to the application by a user). 16.3 Are any components (e.g., encryption) subject to export restrictions? Why or why not? Berkeley DB is not subject to US export restriction, it has been published, and is eligible for export under paragraph 740.13(e) of the export regulations. That said, the BDB product does provide two versions, one with encryption and one without. So far product groups have only ever used the version without encryption, but if a product group wants to use the product with encryption, then it will be restricted as to which countries can download that product. 16.4 How are particularly security-critical data like passwords treated? Berkeley DB overwrites all passwords as soon as it can, however, it is still necessarily vulnerable to processes able to read system memory. 17. Availability and Serviceability 17.1 How will it respond to failures? (Does it ever require reboot? No, it does not require OS reboot Can it lock up?) No 17.2 How does your project deal with network failures (including partition and re-integration)? BDB has an HA product that provides interfaces that allows an application to replicate data to a hot standby. It is the responsibility of the calling application to handle network partitioning and re-integration. 17.3 Can it save and restore state? Yes, it's a database product. 17.4 Can it checkpoint and recover? Can its files be corrupted by failures? Does it clean up any locks/files after crashes? Yes, it uses standard transaction log, roll-forward semantics for recovery 17.5 Will it participate in the Solaris Fault Management Architecture (http://fma.eng/) No. 17.6 Can the project's deliverables be patched and upgraded without requiring a reboot? Without a noticeable service interruption? Reboot will not be required, but the service may need to be restarted. 17.7 How will patches be installed? Binary patches are delivered. 18. Adaptability to a Changing World: 18.1 Any plans for supporting operating systems other than Solaris (Linux, perhaps HP/UX, Microsoft Windows, AIX, etc.)? Already ports to these 18.2 How does it deal with issues in the 64-bit world, including 64-bit address spaces, 64-bit integers, and 64-bit files? BDB is 64-bit compliant. 18.3 How will the project provide services to other projects? 18.3.1 Current or planned usage of CORBA IDL, IIOP, and an ORB? If an ORB, hich one (Bonobo, Java IDL, ...)? None 18.3.2 Current or planned Java Beans, especially J2EE? None 18.3.3 Current or planned Web Services interfaces (SOAP, etc.?) None 18.4 What is its relationship (or difficulties) with . . . 18.4.1 the Internet? Web Services? None 18.4.2 Java? J2EE? Application Servers? None 18.4.3 "Network of Things" (thin clients, portable devices, wireless networking, kitchen appliances with IP addresses?) None 18.4.4 Multimedia? None 18.4.5 Networked storage (SANs, NAS) BDB can be used on SANS without change. 18.4.5 Infiniband? An application using the HA product may choose to replicate transactions over an Infiniband pipe, but the application is responsible for sending the data over a network pipe, so BDB does not directly participate in this. 18.4.6 Network identity services? None 19. Issues? Please identify the issues for which you would like ARC guidance. (e.g. Interface classification, deviations from standards, architectural conflicts, release constraints...) Due to the none uniqueness in name and location of db.jar we will place this file under:- Solaris: /usr/share/bdb45, for BDB 4.2 it's under /usr/share Linux: /opt/sun/share/lib/bdb45, for BDB 4.2 it's under /opt/sun/share/lib/bdb Is sparcv9 a valid subdirectory name for 64 bit? ie: install to /usr/lib/sparcv9/bdb We would like to deliver a source package for BDB 4.5 and looking to ARC for guidance, ie: where to deliver package. Also like guidance on delivering Solaris AMD 64 bit binaries. Any issues outstanding from previous reviews (or the case's mail archive)? N/A 20. Appendices and References 20.1 Interface Tables, Package Manifests, etc [0] sol_packmap.txt - a listing of files in each package, for Solaris [1] Architecture.pdf - a graphical overview of the BDB interfaces 20.2 References to other documents (one-pager, design papers, interface contracts, etc.). Copies are to be placed in the case directory. All Sleepycat documentation is provided in a folder called "docs" in the inception case material. All references here are relative to that folder. All of this documentation is for the 4.5.20 release of Berkeley DB. The table of contents for all documentation can be found at index.html. Of particular value is the programmers reference, found at ref/toc.html (Berkeley DB Programmer's Reference Guide). Ref Location Comments ---- ----------------------------- ------------------------------------- [3] api_c C API documentation [4] api_cxx C++ API documentation [5] java Java API documentation [6] api_tcl TCL API documentation [7] ref/rep/base_method.html [8] ref/env/naming.html How to name a database file. Includes Information about the DB_HOME environment variable and its usage. [9] ref/env/db_config.html The DB_CONFIG configuration file [10] utility/db_archive.html The db_archive utility man page [11] utility/db_checkpoint.html [12] utility/db_deadlock.html [13] utility/db_dump.html [14] utility/db_hotbackup.html [15] utility/db_load.html [16] utility/db_printlog.html [17] utility/db_recover.html [18] utility/db_stat.html [19] utility/db_upgrade.html [20] utility/db_verify.html [21] ref/dumpload/utility.html More information on db_dump and db_load [22] ref/upgrade/process.html How to upgrade Berkeley DB [23] ref/upgrade/version.html Library version information [24] ref/env/security.html An overview of security with BDB [25] ref/env/encrypt.html An overview of encryption features in BDB 20.3 Comments For Us? 20.3.1 How many engineer hours went into preparation of case materials, including answering this questionnaire (that would not otherwise have been needed for other purposes)? 60 engineer hours 20.3.2 Do you think it was time well spent? Mostly 20.3.3 How many engineer hours went into answering this questionnaire alone? 50 engineer hours 20.3.4 Comments on this questionnaire should be mailed to lsarc-chair@sac.eng. 20.3.5 Comments on your case owner, the review process, or the experience may be placed here if they're not too personal, may be mailed to the chair or arc-chairs@sac, or may be expressed to John Plocher (x87604), Cheryl Bisque (x51457) or Rob Gingell (x85555).