Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SMILA/Documentation/Xml Storage::Implementation::Berkley XML DB"
(New page: == XML data storage== == Berkeley DB XML== Oracle Berkeley DB XML is an open source, embeddable XML database with XQuery-based access to documents stored in containers and indexed based ...) |
|||
| Line 8: | Line 8: | ||
== Key Features and Limitations== | == Key Features and Limitations== | ||
| + | |||
| + | == Implementation Ideas== | ||
'''Scenario 1: Parallel Access from diff. Clients on same Host''' | '''Scenario 1: Parallel Access from diff. Clients on same Host''' | ||
Revision as of 04:40, 2 September 2008
XML data storage
Berkeley DB XML
Oracle Berkeley DB XML is an open source, embeddable XML database with XQuery-based access to documents stored in containers and indexed based on their content. Oracle Berkeley DB XML is built on top of Oracle Berkeley DB and inherits its rich features and attributes. Like Oracle Berkeley DB, it runs in process with the application with no need for human administration. Oracle Berkeley DB XML adds a document parser, XML indexer and XQuery engine on top of Oracle Berkeley DB to enable the fastest, most efficient retrieval of data.
The attached docs from Oracle can be found [| here]
Key Features and Limitations
Implementation Ideas
Scenario 1: Parallel Access from diff. Clients on same Host It is possible to configure BDB such that several client processes can access the underlying data concurrently by sharing the underlying database files. This is called environment sharing. For this to work BDB needs to be configured to activate its transaction control as described in [| BerkeleyDBXML-Txn-JAVA.pdf].
However, this approach is limited to diff. clients on the same host. Placing the files on a shared recourse such a SAN, NFS is explicitly no valid solution (see http://www.oracle.com/technology/products/berkeley-db/faq/db_faq.html#30) for accessing the same data from diff. hosts.
Given the targeted environment of a distributed system the current scenarios seems an unlikely use case for EILF. The only situation where this scenario could make sense nonetheless is, if all of the following conditions are met (IMHO this is unlikely to be the case):
- the pre-processing overhead of the client for storing the XML Data is relatively large
- that execution time occurs before transactional synchronization
- parallelization with VM threads is less efficient than with native processes.