11. Scalability

11.1 Downward scalabilty

The library will adapt to most environments, including low-memory, single Store architectures. The memory requirements are proportional to the objects used, and the memory requirements of the user application itself. This means that caches only grow, if the memory expands on behalf of the user application, and internal object state trackers only add overhead to existing objects.

The conclusion is, that the library is capable of running in a few megabytes, with a startup time in the low seconds.

11.2 Upward scalabilty

As described in the previous section, the memory footprint, size of cache will adapt to the memory requirements of the user application. This also means, that is the application uses hundreds of megabytes, the library will proprotionally allow itself (and the cache) to use up memory as it becomes available.

The library is also capable of running in a distributed environment. This means, that in webapplications which are deployed in a clustered server, or load-balanced server cluster. To do this, the library establishes connection with the other libraries (referred to as Nodes in this context), which are connected to the same database. The number of Nodes connected this way is not limited, it can be two Nodes, or even a hundred. This connection between Nodes ensures, that all guarantees which are present on a single Node are extended to all Nodes in the cluster. For example if another Node locks some objects, any other Node accessing them will receive a ConcurrentModificationException the same way, as they were in the same JVM.

When there are multiple Nodes to a database, the Nodes appoint a server Node to coordinate locks, semaphores and other exclusive resources between them. All other Nodes become client Nodes. If a client Node disconnects from the cluster, it has no effect on the other Nodes, all operations continue as if nothing happened. Of course all operations in this disconnected client will throw exceptions, until it can reconnect. When a client reconnects, all operations which depend on some state in the server will cancel. This means, if the client started a Transaction earlier, this Transaction will be rolled back instead of commited, because even if the Node successfully reconnected, the server may in the meantime re-assigned the used resources to some other Node. If a server is removed from a cluster, the remaining Nodes appoint a new server Node, and continue working, with the effects of a reconnect (Transactions rolled back, cache cleared, etc.).

The conclusion is, that BeanKeeper is capable of scaling to a large cluster easily, without any configuration, and can re-organize itself in case of a failure mostly without any effects visible.

This document was generated by Robert Brautigam on November, 21 2009 using texi2html 1.78.