summaryrefslogtreecommitdiff
path: root/src/site
diff options
context:
space:
mode:
authorBrian S. O'Neill <bronee@gmail.com>2006-10-20 21:29:12 +0000
committerBrian S. O'Neill <bronee@gmail.com>2006-10-20 21:29:12 +0000
commitb74189ce76ce2c69087eaa3eebd845ae4b6d0cf8 (patch)
treeb696814022c049a6981d67e28f3108a87491e5fd /src/site
parente3c30458c08d402b8baeb1a82e2cea04c428e64f (diff)
Minor fixes.
Diffstat (limited to 'src/site')
-rw-r--r--src/site/apt/index.apt30
1 files changed, 15 insertions, 15 deletions
diff --git a/src/site/apt/index.apt b/src/site/apt/index.apt
index f9a1ec1..197d3d2 100644
--- a/src/site/apt/index.apt
+++ b/src/site/apt/index.apt
@@ -6,7 +6,7 @@ Carbonado
Carbonado is an extensible, high performance persistence abstraction layer
for Java applications, providing a relational view to the underlying
-persistence technology. The persistence layer can be a JDBC accessible SQL
+persistence technology. Persistence can be provided by a JDBC accessible SQL
relational database, or it can be a BDB. It can also be fully replicated
between the two.
@@ -31,7 +31,7 @@ configuration files. All the code to implement types is auto-generated, yet
there are no extra build time steps.
Carbonado is able to achieve high performance by imposing very low overhead
-when accessing the storage layer. Low overhead is achieved in part by auto
+when accessing the actual storage. Low overhead is achieved in part by auto
generating performance critical code, via the open source Cojen library.
* Terminology
@@ -74,16 +74,16 @@ replacement for JDBC. These kinds of applications may choose a blend of
Carbonado and JDBC. To facilitate this, access to the JDBC connection in use by
the current transaction is supported.
- The Carbonado repositories that are backed by BDB use a simple rule-based
-query optimizer to come up with a query plan. Cost-based optimizers are
-generally much more effective, since they estimate I/O costs. Carbonado has a
-rule-based optimizer mainly because it is easier to write.
+ The Carbonado repositories that are backed by BDB use a rule-based query
+optimizer to come up with a query plan. Cost-based optimizers are generally
+much more effective, since they estimate I/O costs. Carbonado has a rule-based
+optimizer mainly because it is easier to write.
-* Persistence Layer Requirements
+* Persistence Technology Requirements
Carbonado is capable of supporting many different kinds of persistence
-layers. A minimum set of features is required, however, in order to provide
-enough Carbonado features to justify the effort:
+technologies. A minimum set of features is required, however, in order to
+provide enough Carbonado features to justify the effort:
* Arbitrary keys and values
@@ -99,12 +99,12 @@ enough Carbonado features to justify the effort:
[]
- Ideally, the persistence layer should support transactions. If it does not,
-then its transactions must be implemented by batching updates in memory. Upon
-commit, the updates are made to the persistence layer. If atomic batch updates
-are supported, then the repository can report supporting an isolation level of
-"read committed". Otherwise, it can only support the lowest level of "read
-uncommitted".
+ Ideally, the persistence technology should support transactions. If it does
+not, then its transactions must be implemented by batching updates in
+memory. The updates are not persisted until the transaction is committed. If
+atomic batch updates are supported, then the repository can report supporting
+an isolation level of "read committed". Otherwise, it can only support the
+lowest level of "read uncommitted".
Additional features which are nice to have, but not strictly required: