This was discussed at length a few weeks ago (I forget where now, possibly IRC). We concluded that being able to intercept test methods for the purpose of declaring a transaction rollback is a very flimsy edge case. A far more robust approach is to inject the UserTransaction or EJBContext and invoke the method to mark the transaction for rollback.
But you should only be doing that if you are testing that the transaction operations can be rolled back (for instance, XA transaction atomicity). You should not be rolling back the transaction to forgo modifying a production (or test) database. The reason is, rolling back a transaction often causes the writes to be bypassed altogether (a typical optimization of write-behind frameworks like JPA). In this case, your test is not able to validate that the writes will actually succeed if attempted, and hence you have a meaningless test. If you are testing database updates, you should let the update complete, commit the transaction, then in a separate transaction (even a separate entity manager), make sure the data is there.
So be careful what you wish for