Similarly, the Versata Logic Server offers failover, which guards users against server-connection problems. If a Versata Logic Server goes down, the user is informed and is asked to restart their application while a connection is made to another pooled server. However, the Versata Logic Server does not support fault tolerance, which would continue the current session on a different pooled server if the primary server goes down.
The Versata Logic Server does support, however, a nice implementation of connection pooling, which allows all clients logging into a data source with the same ID to join one connection pool for that server. These clients must be created in the Versata Studio environment, however. We’re not going to get into the specific mechanics of connection pooling (mechanics that are, by the way, very well explained in the Versata Logic Server documentation), since it’s as much a development issue as it is a deployment issue.
Adding together all these capabilities however, translates into a very scaleable solution. If your Versata Logic Server is bogged down, it’s easy enough to add another server or two and distribute the workload without making huge changes to your applications. The Versata Logic Server can also be integrated into a larger enterprise situation, thanks to support of Object Transaction Services, which allows distributing transaction processing via data sources managed by the likes of Tuxedo and Encina. In addition, the administration tools in the Versata Logic Server are excellent, which means that it’s easy to set up a server pool and implement the features described so far.
In addition, the Versata Logic Server features several other performance-enhancing capabilities. On a basic level, the Versata Logic Server uses buffered updates and object caching, not saving data to the database until the user explicitly requests the changes. The Performance Monitor tracks and displays monitoring information, showing how much memory is available, how many user sessions are running, what load they’re placing on the server, how many transactions have been performed by the server, and how many transactions have been aborted by the server. A single session can be monitored with the Tracing Monitor.