Forum: Building VoltDB Applications

Post: avoiding stored procedures

avoiding stored procedures
Oct 14, 2012
Not sure if this is the right forum, but I've been thinking about VoltDB, having heard Michael Stonebraker's talk at Strangeloop.
Basically, I'm not keen up giving up my middleware/ORM-based architecture, even though I understand keeping transactions to limited per-wire call enables a lot of VoltDB's scalability.
So, that's fine, but what if I could still use ORMs and leverage optimistic locking? E.g. in the application layer, do:
val b1 = BankAccount.load(1)
val b2 = BankAccount.load(2)
b1.balance += 10
b2.balance -= 10
So, in typical ORM fashion, load(1) and load(2) are both wire calls, and then in commit(), there is one last wire call to flush any objects that have changed.
Just this by itself would get atomicity, but to get isolation, the UPDATEs could use optimistic locks, e.g. issue a single statement/transaction of:
UPDATE bank_account SET balance = ..., version = version + 1 WHERE id = 1 and version = 2
UPDATE bank_account SET balance = ..., version = version + 1 WHERE id = 2 and version = 3
The keys would be:
1) I'd need VoltDB to rollback the entire transaction if any of the UPDATEs had a modified count of 0.
2) I'd need to be able to send a generic/ORM-generated SQL string to VoltDB, instead of invoking specific stored procedures (which to me is a good thing).
Perhaps writing a meta-stored procedure like this is already possible? It'd need to take N table names/parameters and execute each one, then fail if any of them didn't change a row.
What do you guys think of this approach? It is possible? Maybe eventually?
Obviously I am being somewhat stubborn by wanting to stay with my ORM/middleware safety blanket architecture, but it's what I know and like. And, personally, anyway, I'd be a lot more likely to try VoltDB out if I could stay with a more familiar architecture than moving so much of my logic into the stored procedures.
Oct 15, 2012
ORMS are not a good match for VoltDB. In volt, a stored procedure invocation is a transaction -- there isn't external user transaction control across multiple external commands to the database. We appreciate your curiosity about VoltDB and certainly hope you give it a try -- but the system does not integrate well with an ORM architecture.