Let me first of all state the expected behavior: Silently marking a transaction as rollback-only through a setRollbackOnly call will work as long as you do it at the *outermost* transaction level. If you do it within an inner transaction scope, the outer transaction will see this as a "global" rollback-only and throw an UnexpectedRollbackException - since the code in the outer transaction did not explicitly ask for a rollback, so needs to be notified.
So in your scenario, I would assume that you do the setRollbackOnly within an inner transaction scope. Since you're using <tx:advice>, this could mean that your pointcut is too broad and applies transaction demarcation at multiple levels: for example, at the Controller level as well as at the service level, with the setRollbackOnly call happening in a service - this would lead to an UnexpectedRollbackException at the Controller level.
That said, I would actually argue that you should virtually never be using a programmatic setRollbackOnly call in the first place, or more specifically, a rollback without exception thrown to the caller. This usually indicates inappropriate transaction scopes.
In particular, web data binding should *not* happen within a transaction. Rather, perform data binding without transaction first, then start transactions at the service level *once you decided to process the bound data*, with the bound data brought into the transaction through a merge operation. This way, validation errors don't require a transaction rollback in the first place...
Aside from avoiding programmatic setRollbackOnly calls in your application code, the above approach to validation and transactions also avoids excessive rollbacks in your transaction statistics. Such rollbacks for frequent and perfectly normal user interactions should in particular be avoided in administered environments like a J2EE server installation - with transaction monitoring and (potentially) escalation messages generated for rollbacks.