SQLContainer - compound transactions


yesterday i built a prototype which adds support for compound transactions to the SQLContainer. Multiple SQLContainer are sharing one transaction. If the persistence of one container fails, no container is persistet and all are becoming rolled back.

Well, the current design of the SQLContainer makes this contribution really tricky. But it works.

Is vaadin already working on something similiar since it is an important issue to write save super transactions. Otherwise i would include this feature in my contribution.

Florian Pirchner



I can’t say for 100% certainty, but as far as I know such changes to the transaction handling are not planned. There is also no such ticket in the trac. If you think this is a useful feature, please create an enhancement ticket to the Vaadin trac. It would also be nice if you can share your implementation e.g. in the Directory.

Out of curiosity: which aspects of the SQLContainer design made implementing this especially tricky?


OK, i am adding a ticket and for sure i am going to contribute a completely finished implementation. But to finish the contribution will take about 2 weeks since i am in a customer project and the current solution is a quick hack patch to verify the possibility.

Actually the QueryDelegates are using their own connections. But a shared connection is required to create a compound database transaction. For compound transactions, each delegate has to work against an abstraction above one shared connection. Which means, that each delegate uses its own transaction which are part of a super transaction. Calls to transaction#commit are NOT immediatelly delegated to the connection. Only the commit of the last open sub transaction will trigger connection#commit().

AND for sure, the caches of the delegates and the SQLContainer may only become refreshed if the database connection was successfully. Therefore the SQLContainer#commit() method has to be splitted up in beginTransaction(), store(), postCommit() and postRollback().

AND for sure, the current API has to be saved.

All together makes that implementation tricky.

Florian Pirchner