It's my understanding that the controller should mainly be responsible for communicating with the business layer and preparing the view data when necessary. In that case, it shouldn't have any knowledge about transactions; they should be kept at a lower layer.
When the controller needs to execute some logic that consists of multiple steps where a single transaction would be desired, that logic should be rolled up into a method in the business layer. When managing transactions with Spring, you can easily define a service method as transactional, and how nested calls should handle their transactions: whether to pick up the existing transaction if available, always create new, etc.