Opa also allows multiple instances of an application to run in parallel, and thereby provide application scaling. Requests are load-balanced among the application's instances, and the Opa load-balancer ensures that requests from the same client are sent to the same server. However, although the components that handle scaling are distributed among the application's instances, they are not replicated. Consequently, a distributed Opa application is not fault-tolerant; if one instance dies, the session state of clients served by that instance is lost. As you might imagine, this is an area of intense development for the Opa engineers.
Opa database options
Opa's built-in database works somewhat like a key-value persistent store system. The key is a path that leads down the database tree to a leaf (the value). So, for example, to fetch the value associated with the
message001 leaf of a blog database, you might use code that looks like
blogvar = /blog["message001"]
Because the database uses a tree structure, it is schemeless. No data definition functions are required (or even available) for specifying what data types appear where in the database. Nor are there any restrictions placed on the data types that can be stored in the leaves of the database tree; primitives are handled as easily as complex data structures.
The database's snapshot feature is particularly powerful. Preceding a path with a
! takes a snapshot of that path, and this snapshot can be saved in a variable. Subsequent store operations to values on the path will not affect the snapshot, which remains "alive" as long as the associated variable remains in scope.
However, as flexible as Opa's internal database system is, it is meant primarily to support either prototype applications or applications that do not require data-intensive operations. The database does not scale, and scalability is supposed to be one of Opa's outstanding characteristics. For applications that must manage large databases (or that anticipate database scaling issues) the Opa engineers recommend the use of MongoDB, a well-known NoSQL database system that stores data in the form of BSON (binary JSON) documents.
The current release of Opa provides an evaluation API for MongoDB that includes functions for translating between BSON and Opa data types. Opa's MongoConnection library manages connections with a MongoDB server, handling database cursors as well as automatic reconnection and failover on disconnect. Meta operations -- deleting an entire database, for example -- are available via Opa's MongoCommands module.
Full MongoDB support, as well as support for the well-known CouchDB database, is expected in the upcoming S4 release. Note that the MongoDB and CouchDB modules do not replace Opa's existing database API. You can use the Opa path-oriented database side-by-side with either MongoDB or CouchDB.
Having trouble installing and setting up Win10? You aren’t alone. Here are many of the most common...
Win7 Update scans got you fuming? Here’s how to make the most of Microsoft’s 'magic' speed-up patch
Picking an Android phone can be difficult, but we're here to help. These are the top Android phones you...
Emerging tools and cloud-based services help you get your apps right across devices
Allowing ISPs to sell your data isn’t only about eroding online privacy. It’s also dangerous to U.S....
Attention all technical presenters: At last, a slideshow tool for you! With the open source library...
Managing computer systems, finding bugs, and plugging security holes are all problems that AI will...