*** 12,23 **** expert and may have misunderstood parts of the documentation. If you find errors, you are encouraged to fix them. - *Fundamental Differences* - - Previously it said here that Derby reads the entire database into memory and parses it into various Java data structures, that is wrong. It works very much like a traditional database. - - So, I'm not sure what this part really should contain. - *Overall* Both SQLite and Derby operates directly from disk. Only parts of the database file(s) that are needed in order to carry out the requested operations are read. --- 12,17 ---- *************** *** 47,53 **** SQLite allows multiple simultaneous readers and a single writer. Mutiple processes can have the database open simultaneously. ! Derby can operate in two modes, either as simply embedded when it is available only to once process through direct JDBC connection, or that single process can act as a server taking connections from several clients. Derby has upgradable row-level locking, so high simultanious concurrency without much contention can be achived. *Crash-Resistance* --- 41,47 ---- SQLite allows multiple simultaneous readers and a single writer. Mutiple processes can have the database open simultaneously. ! Derby can operate in two modes, either as simply embedded when it is available only to once process through direct JDBC connection, or that single process can act as a server taking connections from several clients. In server mode, Derby has upgradable row-level locking, so high simultanious concurrency without much contention can be achived. *Crash-Resistance*
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|