Thank you, Paul. This information is really helpful. I'm scouring through the documents to determine whether we can go ahead with VolDB at this point. Our current application (stock trading platform) has its business logic done entirely in stored procedures (MSSQL). It is simply not feasible for me to rewrite all our applications to move logic to the application layer. Therefore, I would be adopting MSSQL stored procedures into VoltDB. Which is a good thing since VoltDB's procedures are in Java. However, this means that single stored procedure would need to load data from many different tables and/or modify data in different tables and also call other stored procedures which will modify their own set of tables. The fact that all this will be done in single transaction is good news to me (really good news), but can VoltDB's stored procedures be so complicated? Is it possible to use Java's collections framework from within VoltDB? Can I create arbitrary classes within VoltDB to perform calculations?
There are very few restrictions on what stored procedures are allowed to do or to call.
I already mentioned previously in this thread the restrictions around calling other stored procedures -- that is, having the run method of a class derived from VoltProcedure call another run method, whether directly or indirectly, to delegate database access.
The other class of restrictions is related to determinism of inputs to database write operations (DML statements). VoltDB is designed to support both k-safety ("live" redundancy) and WAN replication. To ensure the integrity of the database when one of a set of redundant servers is taken down, or when the database must switch over to a remote backup, it is imperative that each stored procedure invocation have an identical effect on the database wherever/whenever it is run, based solely on the procedure's input parameters. The executed SQL statements and their parameters must be a result (direct or indirect) of the stored procedure's input arguments and not influenced by other factors that might be available to a java program -- like the current time, or the results of a random number generator, or a reading from a temperature sensor or a local file. Basing DML statement choices and/or their parameters on such "variables" is likely to run afoul of VoltDB's internal integrity checking, which can have serious consequences. Such "external data" must be provided by "the database clients" through stored procedure parameters. Aside from this determinism restriction, stored procedures have full access to the power of the jvm and anything that can be packaged into jar files and run on the architecture of the host machines.